So back to the good old, reliable rsnapshot for daily, during-the-night backups.

There is catch that has been bothering me for quite some time, though, and I only found the solution very recently.

I like my Snow Leopard iMac to go to sleep after a reasonable period of time, because it is not meant to stay up 24×7 – unlike the Ubuntu backup/storage/kids game machine.
The iMac is fairly clever in that it can wake up from simple SSH requests – or from the preceding ARP requests.
Here is the issue: I want rsnapshot to wake up the iMac before the backup – and obviously let it go back to sleep afterwards.

Scripting the ability to wake up the iMac is not a big deal. This simple script would do:
#!/bin/bash
let "i=0"
sshup=1
while [ $i -lt 20 -a $sshup -ne 0 ]
do
let "i += 1"
sleep 2
ssh $IMAC echo
sshup=$?
done
exit $sshup


Their needs to be some ssh trust relationship in place between the backup server and the iMac; enough articles have been written on that topic, I will not contribute to the noise.

Inserting this script (let’s call it /usr/local/sbin/ssh_wake) in the rsnapshot workflow is not a big deal, thanks to the cmd_preexec configuration item in rsnapshot.conf:
cmd_preexec /usr/local/sbin/ssh_wake

(do mind that like usually there is a TAB between cmd_preexec and /usr/local/sbin/ssh_wake)

However, this design comes with an issue: in its default sequence,

• rsnapshot starts by launching cmd_preexec (hereby waking up the iMac),
• then rotates the backup directories (daily.n becomes daily.n+1),
• then rsyncs the backup.

On fairly large backups, there is going to be a significant delay between the « let’s wake up the iMac » and the « let’s perform the rsync data transfer ». To a point where the iMac would go back to sleep before the actual data transfer.

Quite a few weeks banging my head against that one.

Until I started reading the rsnapshot source code (it is only Perl after all ™), and noticing this sync_first configuration item that changes significantly the usual workflow.
sync_first was nowhere to be found in my rsnapshot.conf, because my configuration file dates back to a version of rsnapshot that did not support sync_first.
Makes you feel like a dinosaur. Just a bit.

A bit of RTFM later, here is how sync_first works:

• sync_first decouples data transfer and directory rotation, which by itself warrants my interest
• If there is no .sync folder in the backup directory (same level as the daily.X), then rsnapshot copies daily.0 to .sync
• If there is a .sync, then use it as a helper for the rsync data transfer
• Once the data transfer is completed, copy (hard link the usual rsnapshot way) .sync to daily.0

The key in all of this is that I can sneak in my cmd_preexec right before the data transfer, provided that I use this sync_first. Directory rotation and clean-up happens after sync, hence the sync_first.
In rsnapshot.conf:
sync_first 1

(TAB, again)

So the daily cron job just needs to be doing the following:
/usr/local/sbin/ssh_wake && \
/usr/bin/rsnapshot -c /etc/rsnapshot.conf sync && \
/usr/bin/rsnapshot -c /etc/rsnapshot.conf daily
(or whatever variation using ionice to lessen the I/O load on the backup server)

Final caveat: this sequence is likely to fail the first time it is executed, because the .sync directory does not exist yet.
But starting with the second day… things start working as expected. Voilà!

Un peu de recherche sur le web, cela peut être du à une alimentation de mauvaise qualité – problème qui avait déjà été identifié.

Après plusieurs tentatives de redémarrage, la solution la plus robuste semble de mettre le disque dur de sauvegarde dans un boitier USB externe.
Plus de bruit depuis.

Rétrospective et hypothèse du jour : ce n’est pas vraiment HP qui nous a vendu cet unité centrale, c’est Apple. Avec pour plan machiavélique de nous dégouter du monde des PC pour de bon, et nous faire acheter un iMac. Ça se tient, non ?

Comparaison de prix rapide : un iMac 2.8 GHz Intel Core i7, écran 27 pouces, RAM 4 GB DDR3 1066 MHz, disque dur 1 To, carte graphique ATI radeon HD 4850 512 Mo, lecteur/graveur DVD double couche, carte son avec sortie numérique, souris Magic Mouse bluetooth, carte son, FireWire, sans-fil 802.11n, haut-parleur intégré, clavier international avec pavé numérique coûte 17 190 NOK livraison comprise. Et produit 18 dBA au repos.

Pour un équivalent PC, petit saut sur le site de Dell, gamme semi-professionnelle (on ne me surprendra plus à taper dans la gamme grand public) : un Dell Precision T1500, Windows 7 Professionnel 64 bit (je ne me fais pas d’illusion quant à la possibilité de remboursement de la taxe Microsoft pour installer un Ubuntu Lucid à la place), Intel Core i7 2.8 GHz, RAM 4 GB DDR3 1066 MHz, carte graphique NVidia Quadro FX 580 512 Mo, adaptateur DisplayPort to DVI, disque dur 1 To, lecteur/graveur DVD 16x, carte son Sound Blaster, Firewire, sans-fil 802.11n, anti-virus Tend Micro pour 15 mois, écran Dell UltraSharp 24 pouces, haut-parleurs, clavier, souris sans-fil, DVD avec pilotes coûte 22 214 NOK livraison comprise (17 371 NOK hors livraison). Pas de précision sur le niveau sonore.

Point de vue WAF, y’a pas photo.

Suffisamment en tous cas pour jeter un coup d’œil approfondi à Google Chrome.
Comme tout le monde, on commence par aller voir chez Google, qui nous offre un lien vers un paquetage Ubuntu 64 bits. Parfait.

Sauf que… Qu’est-ce qui me garanti que le paquetage va être mis à jour ?
Je n’ai aucune envie d’aller vérifier régulièrement la dernière version, et je tiens en horreur les systèmes de mise à jour ad-hoc qui dépendent des lubies de chaque éditeur de logiciel.

Dans le genre, il a été servi le Guillaume.

Le paquetage google-chrome-beta installe un script /etc/cron.daily/google-chrome (qui s’exécute donc tous les jours). Ce script rajoute une clef d’authentification apt (ces clefs qui identifient les sources de paquetages auxquelles apt fait confiance) :
pub 1024D/7FAC5991 2007-03-08
uid Google, Inc. Linux Package Signing Key sub 2048g/C07CB649 2007-03-08

Le script s’assure aussi que la source de paquetages Google est réactivée en cas de mise à jour de la distribution.

Nous voici face à un paquetage qui s’occupe de lui-même d’assurer ses mises à jour et d’authentifier son éditeur auprès de mon apt. Qui se fait suffisamment confiance pour ajouter une clef d’authentification qui n’a pas été plus vérifiée que ça, comme elle a été servie en texte clair. Qui ouvre la porte à plein d’autres applications Google – la ligne sources.list.d/google-chrome-list est très générique :
deb http://dl.google.com/linux/deb/ stable main

Dubitatif le Guillaume.

J’aurais quand même bien aimé qu’on me demande mon avis.

Alternative numéro deux, dégainer iTunes depuis son canapé. 4 $ (3 €) pour louer un DVD pour 24 heures, vaste choix, dans la dizaine de minutes de téléchargement en ADSL 2. Pour ceux qui ont précieusement conservé leur compte iTunes américain.

Alternative deux testée samedi soir, très convaincante.

$ sudo grep -R mirrordir /usr/local/sbin/ | wc -l
2

Il semble que la cause est la taille des cylindres du WD15EARS : 4096 octets au lieu des 512 octets habituels. Western Digital n’a pas cru bon d’informer les pilotes de cette particularité, et retourne un bien mal avisé 0 :

# hdparm -i /dev/sdb
/dev/sdb:
Model=WDC, FwRev=80.00A80, SerialNo=WD-WMAVU1504767
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=2930277168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode

Dur dur pour partitionner son disque selon des partitions alignées correctement, dans ces conditions.

À la lecture de cet article, on se dit que finalement XFS est fort sympathique et qu’un re-partitionnement s’impose.

Le mode d’emploi est assez explicite : pour avoir une seule partition XFS qui couvre tout le disque,

# parted /dev/VOTRE_DISQUE_DUR
(parted) mklabel
-> gpt
# Testé uniquement avec le format de table de fichier GPT
(parted) unit s
# On choisit le nombre de secteurs comme unité de mesure
(parted) mkpart primary xfs 40 -1
# Parted va se plaindre du secteur de fin :
Warning: You requested a partition from 40s to 2930277167s.
The closest location we can manage is 40s to 2930277134s.
Is this still acceptable to you?
Yes/No?
# La bonne réponse est "Yes"
(parted) quit

La création du système de fichier n’a rien de particulier :

# mkfs.xfs /dev/PARTITION

À première vue, les performances ont l’air d’être de retour.

Valérie est occupée ces jours-ci à mettre à jour ses cours, DS et DM.

Au siècle dernier, emacs permettait déjà de vérifier l’orthographe de documents tapés en LaTeX. ispell (correcteur orthographique) avait l’intelligence de ne pas considérer les balises de LaTeX comme des fautes d’orthographe.

Kile en est incapable sous Ubuntu depuis au moins deux versions (donc un an). Il s’agit d’un bug qui n’a que trop duré.

La solution tient en la mise à jour de kde désormais disponible en PPA, via un

$ sudo add-apt-repository ppa:kubuntu-ppa/backports
$ sudo aptitude update
$ sudo aptitude safe-upgrade

Cerise sur le gateau, après la mise à jour Kile peut souligner les fautes d’orthographe à la volée.

Avais-je déjà mentionné que sous Mac, corrections orthographiques mais aussi grammaticales viennent du système d’exploitation ? Et sont donc disponibles aux applications sans même vraiment en faire la requête…

Vint alors Thunderbird 3.

Recherche très rapide et très complète. Onglets joliment intégrés. Support pour IMAP performant. Bonne intégration avec LDAP.

Premier hic : il formate parfois bizarrement les réponses en ligne à des mails HTML (on ne sait plus qui écrit quoi).

Deuxième hic : son support de OpenPGP (via Enigmail) ne m’a pas emballé à première vue (le truc est incapable de relire un mail qu’il a lui-même chiffré).

Défauts de jeunesse ?