colin@
colino.net

Since a few years, our website, www.claws-mail.org, has been hosted by the nice people of Develog. Our CVS and mailing-lists were hosted on dotsrc.org, another bunch of nice guys offering hosting to free software projects since years.

However, they’re starting to lack time and manpower to continue providing hosting — I guess they’re, like us, getting older and more and more busy with real life — and are in the process of shutting down hosting.

I’ve grabbed our multiple-year CVS history, and mailing-lists archives and subscribers lists from them, and after asking Yann, I’ve moved them on the same host as www.claws-mail.org.I’ve updated our CVS and Community pages to reflect the changes.

It should provide us with good quality hosting, and it also has the benefit of being free (as in beer) — thanks Yann ! Another advantage is that as Yann trusts me, I have a fair amount of control over the server, if needed.

It has only one drawback, as this server is Yann’s, and his job isn’t to provide free hosting to free software projects, that’ll add a bit of admin-load on my free time. But, mostly, it works and I won’t have a lot to do. I can also do-outsource backups, which makes me feel safer (for a little bit of time, I thought Dotsrc would leave us with no CVS history, which was a freaky thought).

Finally, I’ll be able to migrate us to Subversion or some other version-control software, if and when we agree on something, and I can get some time to do the migration and related (related is what takes some time, I’d have to change our tracker for something like Trac, change my buildbot scripts, fix the commit mail scripts, and other things I probably forget).

Now that we’re in 2009, it’s been a few years since we’re more and more aware that energy is a valuable resource that should be spared. Where I work I’m handling a medium-sized datacenter of 160 servers, and they use approximately 28 kW of power. 28.000 watts, that represents 470 light bulbs, always on, burning day and night.

To this, we can add the cooling system’s consumption, which we don’t monitor but we can safely add 3 to 8 kW for the three cooling units, depending on the outside temperature. That’s what fun about datacenters, we have to burn electricity to cool down the room heated by the servers’ electricity consumption. Consider it the equivalent of putting the oven in your fridge when you bake a cake.

We’ve been trying to minimize a bit this consumption. There’s an article there that writes about shutting down servers when they’re not in use – ie, at night, or during the week-end.

Well, we thought of it first ! :-) In my opinion, it isn’t possible to shutdown every server at night : the backups run during the night, and saving its data is much more important to a company than saving electricity – sadly in some sense… So, we can’t shutdown production servers with important data on it. Luckily, where I work, a very large part of the datacenter is used for development and testing – we’re doing cluster-oriented storage, we have clusters, and about 140 out of our 160 servers are completely unused at night: developers go home.

So, one year and half ago already, I’ve implemented a way for developers to tell whether their test servers could be shutdown at night or not (in case they have long-running tests on them). It’s not a huge success, mainly because people choose 24/24 instead of 12/24 “just in case”, I think, but with approximately 30 servers down every night and during week-ends, we still spare 8 kW more than half the time. Still better than nothing…

Besides, at home, I’m now putting my laptop to sleep when I’m not in front of it. The saving’s much less and completely nullified by the server in the cupboard, but it’s still better than the days where I had three servers in the cupboard and didn’t put my laptop to sleep !

Since I’ve blogged about my little Quitcount tool, I’ve received a Hungarian translation from Páder Rezső, a German translation from Fabian Affolter, and an Italian translation from Salvatore de Paolis, and fixes from a few other people (most of them I already know from Claws Mail, heh :-) Thanks guys! I’ve released 1.5 to have them in a tarball, because this little tool will probably end up packaged in a few distros :-)

Paul (my friend, not my son) said to me some time ago, “Still obsessed with smoking, I see ;-)”. That made me realize that indeed, stopping smoking sometimes make me think more about it than I did when I smoked. I guess that’s rather logical, I’m still in the long process of readjustment (of my habits, my neurons and my brain). My sister quit years ago and still thinks of it from time to time, too. She showed me she still has a quit counter widget loaded on her Mac OS X, with really big numbers on it, and I looked for one on my XFCE desktop. I didn’t find any, though, so I wrote one myself :-)

Ladies and gentlemen, I hereby present you QuitCount, a little piece of software that has no other practical value than keeping yourself motivated if you try and quit smoking, and in a second phase, impressing yourself with big numbers (I already didn’t inhale more than 12 grams of tar).

You can also use it as a start counter to see how much you smoked since you started, but don’t; that’s scary.

Translators and packagers welcomed!

Levebvre, porte-parole de l’UMP, après que le conseil constitutionnel aie tranché en défaveur de certains points de la loi création et internet (Hadopi): “Les socialistes [...] n’ont pas de quoi être fiers. [...] après le recours devant le Conseil constitutionnel, ils auront des comptes à rendre aux artistes et dans les urnes“.

Riester: “Le texte permettait déjà aux internautes de déposer un recours devant le juge. On gagne une étape, on va directement au juge. Donc le caractère dissuasif sera encore plus fort“. À part le fait que ta loi foulait la présomption d’innocence aux pieds, t’as tout compris…

Veut-il dire qu’ils auraient préféré passer une loi anticonstitutionnelle sans rien demander à personne ? Y’en a vraiment qui doutent de rien…

Enfin, je me rends compte que bien que ces gens m’indignent, j’arrive mal à expliquer pourquoi. Mon avocat préféré y arrive beaucoup mieux.

Some time before Christmas, I was looking for a nice gift to Clo and had a idea I found good: a good quality printed version of her blog, for the souvenir, would be quite unique and nice.

Problem is that printing it would be really painful, with about 80 posts, I didn’t want to do that manually and thought it’d be better to be able to automate that with html2ps or something like this.

html2ps having a really crappy rendering, I investigated Webkit and found it would print nicely, but it only supported printing via print dialog, which was painful too. So I dived into webkit-gtk’s code and patched it and added support for PDF export (via GTK+ print support); then proceeded to write a little app to batch-export to PDF a list of URLs.

That done, I used pdftk (the PDF ToolKit) to concatenate all these PDFs into a big one, uploaded it to lulu.com and there was the result:

Some more iterations of the webkit patch later and with the help of Gustavo Noronha of GNOME fame, an official API was defined, implemented and commited to Webkit. After reworking my app a bit to fit this API, I’ve been able to test it with the second volume of Clo’s blog (yes, she writes quite a lot, this second volume has 350 pages for little Paul’s first six monthes !), and here’s a new piece of free software born: webkit2pdf. It requires a fairly recent Webkit version; I’m not even sure they released since the patch’s in.

À force de lire des articles sur les ondes pulsées du réseau GSM, qui nous émettraient trop fort dans les cerveaux, provoquant des cancers et des maux de têtes (mais pas dans cet ordre), j’ai voulu voir par moi-même l’étendue des dégâts concernant ces antennes.

Il paraît que le consensus scientifique est qu’un seuil d’exposition inférieur à 0.6V/m est réputé non dangereux pour la santé, et certaines associations comme Robin des Toits militent pour atteindre un tel seuil partout sur le territoire. Le but est noble, mais le ton alarmiste et je n’aime pas le ton alarmiste, surtout que les médias relaient (héhé) bien souvent les cris Au Loup sans aucune analyse derrière.

N’étant jamais si bien servi que par moi-même, après avoir regardé sur le site de l’ANFR, Cartoradio, à combien de V/m j’étais exposé à la maison, et après avoir trouvé ces chiffres (entre 0.11 et 0.51 V/m selon la bande) très peu inquiétants, je me suis demandé si j’étais juste chanceux ou si la plupart des antennes relais arrosaient déjà relativement peu.

J’ai donc enregistré toutes les pages de mesures de l’ANFR de la numéro 1 à la numéro 16328, modulo celles qui n’existent pas, grâce à ce script ; notez bien qu’une pause de 2 secondes a été insérée entre chaque enregistrement, pour le cas improbable où j’aurai pu mettre leur serveur à genoux à moi tout seul.

Profitant du fait que chacune des pages est sur le même modèle, j’ai ensuite extrait les valeurs correspondant aux émetteurs GSM avec ce script vers ce fichier CSV, que j’ai ensuite importé dans une base MySQL (car je suis nul en tableur) afin de pouvoir manipuler toutes ces données. Pour ceux qui sont nuls en base de données, il est aussi possible de l’importer dans un tableur en utilisant le séparateur de champ “,”. Pour ceux qui ne font pas confiance au fichier CSV, mes scripts sont disponibles pour le refaire.

Voici quelques résultats. J’ai été surpris de voir le niveau moyen et médian augmenter au fil des années : j’aurais pensé que, la technologie évoluant, les émissions auraient nécessité moins de puissance. J’ai aussi été surpris de voir une médiane inférieure ou égale à 0.6V/s : suite au bourrage de crâne des médias, je supposais qu’on était assaillis d’ondes néfastes en permanence. Ceci dit, ce schéma sur la FAQ de l’ANFR a tendance à montrer qu’il faut, pour être irradié dans les règles de l’art, se mettre pile en face d’une antenne relais. En dessous, on ne risque pas grand chose.

Quant au wifi, à 0.3V/m à 40 centimètres de la borne, à mon avis, ce n’est pas vraiment la peine de flipper du hotspot de l’hôtel d’à côté. Robin des Toits mentionne aussi la dangerosité du Bluetooth (portée de 10 à 100 mètres) ou encore des tags RFID (portée de quelques centimètres dans la majorité des cas – on trouve par exemple un tag RFID dans les systèmes de déverrouillage de portes à ventouse) ; de mon côté, j’émets (huhu) quelques doutes là dessus. L’ANFR ne mesure même pas ce type d’émission.

Ceci dit, on fait dire ce qu’on veut aux statistiques, donc j’enjoins quiconque est intéressé de faire ses propres statistiques, à partir du fichier CSV, et de me prouver que mon cerveau est déjà fondu.

Quelques chiffres que j’ai trouvé intéressants :

Nombre total de mesures : 14829
Nombre de mesures avec signal <= 0.6 V/m : 9584 (64.63 % du total) (entre 0 et 0.6 V/m :9584 – 64.63 % du total)
Nombre de mesures avec signal <= 1 V/m : 11500 (77.55 % du total) (entre 0.6 et 1 V/m :1916 – 12.92 % du total)
Nombre de mesures avec signal <= 2 V/m : 13429 (90.56 % du total) (entre 1 et 2 V/m :1929 – 13.01 % du total)
Nombre de mesures avec signal <= 4 V/m : 14353 (96.79 % du total) (entre 2 et 4 V/m :924 – 6.23 % du total)
Nombre de mesures avec signal <= 10 V/m : 14780 (99.67 % du total) (entre 4 et 10 V/m :427 – 2.88 % du total)
Nombre de mesures avec signal <= 20 V/m : 14821 (99.95 % du total) (entre 10 et 20 V/m :41 – 0.28 % du total)
Nombre de mesures avec signal <= 30 V/m : 14827 (99.99 % du total) (entre 20 et 30 V/m :6 – 0.04 % du total)
Nombre de mesures avec signal <= 50 V/m : 14829 (100 % du total) (entre 30 et 50 V/m :2 – 0.01 % du total)

Nombre de mesures par puissance, de 0 à 5 V/m

Nombre de mesures par puissance, de 5 à 50 V/m

Les quatre mesures dont le signal est supérieur à 25 V/m sont : 8165, 8166 et 8181 (même endroit) et 13919. La distance de mesure est de 1, 3, 3 et 5 mètres pour chacune d’elles et la zone de mesure est interdite au public.

Moyennes :

Moyenne des 227 mesures en 2001 :0.67 V/m – médiane 0.3 V/m – distance moyenne* : 53.83 m
Moyenne des 741 mesures en 2002 :0.5 V/m – médiane 0.2 V/m – distance moyenne* : 66.68 m
Moyenne des 1632 mesures en 2003 :0.57 V/m – médiane 0.3 V/m – distance moyenne* : 80.79 m
Moyenne des 1737 mesures en 2004 :0.7 V/m – médiane 0.4 V/m – distance moyenne* : 63.71 m
Moyenne des 1941 mesures en 2005 :0.84 V/m – médiane 0.4 V/m – distance moyenne* : 72.4 m
Moyenne des 2634 mesures en 2006 :0.9 V/m – médiane 0.4 V/m – distance moyenne* : 72.29 m
Moyenne des 2380 mesures en 2007 :0.89 V/m – médiane 0.4 V/m – distance moyenne* : 62.7 m
Moyenne des 2525 mesures en 2008 :0.97 V/m – médiane 0.5 V/m – distance moyenne* : 66.5 m
Moyenne des 1007 mesures en 2009 :1.08 V/m – médiane 0.6 V/m – distance moyenne* : 81.23 m
Moyenne des 14829 mesures :0.83 V/m – médiane 0.4 V/m – distance moyenne* : 69.73 m

Moyenne et médiane des mesures, par an

*: les distances sont faussées par la présence de données vides et de données floues dans les données ANFR (‘50 m – 100 m’ compte pour 50, ‘<50 m’ compte 0, par exemple).

D’expérience, ça ne sert à rien de le dire. Il faut l’expérimenter pour s’y mettre.

Songez à ce que contient le disque dur de votre ordinateur. Des documents, des emails, de la musique, des photos, des films. Sur les photos, les emails, et les films, on peut retrouver des moments normaux : un pique nique, une discussion sur les horaires de train pour les vacances de 2003. On peut aussi y retrouver d’autres moments : votre mariage, préparation, photos du jour J, photos du lendemain ; votre fils à sa naissance, à 2 jours, à deux semaines ; un voyage à l’autre bout de la terre…

Voici à quoi ressemble ledit disque dur :

Le plateau tourne à 7200 tours par minute, et la tête de lecture flotte à une dizaine de microns au dessus, ce qui se représente un centième de l’épaisseur d’un cheveu.

La question n’est donc pas si, mais quand cette belle mécanique va faillir. Lorsque ce sera arrivé, tous les fichiers stockés dessus disparaîtront à jamais. Et même si vous en êtes conscients, ça vous arrivera car vous aurez repoussé et repoussé le moment de mettre une bonne sauvegarde en place, jusqu’à trop tard.

Maintenant que vous avez expérimenté la perte de quelques gigaoctets de données irremplaçables, le moment est venu de la mettre en place, cette sauvegarde. Il y a différents points à suivre :

Mauvaise sauvegarde

• Procédure manuelle (insertion d’un disque externe ou d’un DVD vierge, opérations manuelles pour copier les fichiers) : vous allez en avoir assez très vite et le problème réapparaîtra.
• Sauvegarde non testée : Une fois les fichiers sauvegardés on met tout ça dans un placard et on n’y pense plus. Tant qu’on n’a pas relu les fichiers présents sur la sauvegarde, on ne peut être sûr qu’elle est correcte.
• Sauvegarde sur un unique média : Si la panne arrive au début d’une sauvegarde, celle-ci sera vide. Il faut au moins deux médias.

Bonne sauvegarde

• Automatique : crontab sous Linux, tâches planifiées sous Windows, Time Machine sous Mac OS X.
• Sur deux médias ou plus : par exemple deux disques externes, ou une sauvegarde distante : Dropbox par exemple.
• Vérifiée à intervalles réguliers.

Oui, c’est pénible, mais ça vaut le coup. Je me suis fait avoir une fois, ma mère s’est faite avoir une fois, des milliers de gens se font avoir chaque jour et perdent les photos de leurs enfants ou les 2 ans de travail passés sur leur thèse.

Dear readers,

I’ll stop renewing one of the domain names I have, geekounet.org, because I don’t use it enough. It expires on April 12th.

If someone there is interested by this domain name, just tell me, I’d rather transfer it to someone I appreciate than to let the domain squatters get hold of it.

Update: I’ve started the transfer procedure to Pierre, who’s going to make a much better use of the domain than these idiot professional-domain-grabbers.

Here’s a quick  recipe to easily enlarge a RAID1 array with the least possible downtime, using linux 2.6 and mdadm.

We’ll start with a two-disk setup, /dev/sda and /dev/sdb, containing two arrays, /dev/md0 and /dev/md1. /dev/md0 is mounted on / and /dev/md1 is mounted on /backup. We want to grow /dev/md1 from 230GB to 898G (switching from 250GB disks to 1TB).

/dev/md0 has /dev/sda1 and /dev/sdb1, /dev/md1 has /dev/sda3 and /dev/sdb3, while swap partitions are on /dev/sda2 and /dev/sdb2.

Obligatory warning: Use your own brain when following this procedure. Don’t follow me blindly – it’s your data at stake.

Booting on degraded array: don’t shoot yourself in the foot.

When you’ll remove one of the existing disks, your computer won’t be able to boot if grub isn’t installed on the other disk’s bootsector, so make sure that grub is installed on both disks’ MBR:
#grub
grub> find /boot/grub/menu.lst
(hd0,0)
(hd1,0)
grub> root (hd0,0)
grub> setup (hd0)
grub> root(hd1,0)
grub> setup (hd1)

Shutdown the computer, remove sdb, put in one of the new 1TB disks in place, and reboot. Booting can take some time while the initrd’s mdadm tries to find the missing disk.

You’ll boot with degraded arrays, as shown there:
#cat /proc/mdstat
md0 : active raid1 sda1[0]
19534912 blocks [1/2] [U_]

md1 : active raid1 sda3[0]
223134720 blocks [1/2] [U_]

Now, we’ll dump sda’s partition table:
#sfdisk -d /dev/sda > partitions.txt

Edit the partitions.txt file to remove the size=xxxxxxx field on the sda3 line, so that the biggest possible partition size will be used. The file will look like:

# partition table of /dev/sda
unit: sectors
/dev/sda1 : start=       63, size= 39070017, Id=fd, bootable
/dev/sda2 : start= 39070080, size=  1959930, Id=82
/dev/sda3 : start= 41030010, Id=fd
/dev/sda4 : start=        0, size=        0, Id= 0

Disk initialisation

Now partition sdb using this table:
#sfdisk /dev/sdb < partitions.txt

recreate swap if needed:
#mkswap /dev/sdb2; swapon -a

Put sdb back in the arrays:
#mdadm –manage /dev/md0 –add /dev/sdb1
#mdadm –manage /dev/md1 –add /dev/sdb3

Wait until the array is resynchronised and clean. I use:
#watch cat /proc/mdstat #(quit with Ctrl-C)

Install grub on the new disk using grub, like previously (sdb is hd1 for grub), so that you’ll be able to boot from it.

Changing the second disk

Shutdown, remove sda, put the second new disk in place of it, and reboot – make sure your BIOS is configured to try and boot on both drives.

Now you’ll have degraded arrays again:
#cat /proc/mdstat
md0 : active raid1 sdb1[0]
19534912 blocks [1/2] [_U]

md1 : active raid1 sdb3[0]
223134720 blocks [1/2] [_U]

Redo the whole disk initialisation section, this time on sda instead of sdb. Don’t forget to reinstall grub on sda.

In the end you’ll get your arrays clean as they were before, but /dev/md1 will still be 230GB instead of using the whole available room on the disks’ partitions 3.

Grow the things

Let’s ask mdadm to take the whole partitions size for md1:
#mdadm –grow /dev/md1 –size=max

You’ll have to wait for synchronisation again (watch cat /proc/mdstat).

The only remaining thing is to grow the ext3 filesystem sitting on md1, and that’s where the most downtime happen (your data won’t be available unless you do a live FS resize, which I didn’t want to test); these steps took about 30 minutes to complete for me:
#umount /dev/md1
#e2fsck -f /dev/md1 #(it’s better to force a check to avoid a resize failure)
#resize2fs /dev/md1 #(this makes the filesystem the biggest possible)
#e2fsck -f /dev/md1 #(verify that everything is OK)
#mount /dev/md1 #(and you’re done, as df -h should show you):

# df -h /dev/md1
Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              898G  228G  634G  27% /backup

Rambling about half-finished RAID setups

One thing you may have noticed is that I’m installing grub on both drives. This can seem evident, but most software RAID arrays I’ve seen couldn’t boot out of the second disk for lack of an MBR. It makes the RAID setup useful when your second disk fails, but if it’s the first, you’re forced to resort to a rescue CD or PXE boot to reboot your server. This makes things much harder to fix, provokes cold sweats, downtimes, and user annoyment. Install grub on both disks. Check the system boots when removing one disk, both the first or the second, before going into production. Don’t misunderstand your RAID arrays as a backup system. RAID arrays provides redundancy and eases (a LOT) recovering from a failed disk, but it doesn’t eases recovering from two failed disks; and it doesn’t recover lost data from human mistakes either. Regarding failed disks, best results are achieved by monitoring the disks – with smartd for example – and replacing suspicious disks too soon rather than too late.