One of the processes indexes the content of a database table (hosted on /dev/sda) and store it on /dev/sdb on an hourly basis, in order to speed up some searches.
Impact of the increased RAM over this process?

You guessed it, the RAM upgrade happened on the 16th.

What about the overall memory utilization?

The dreadful committed memory got reduced to much more sane levels, whereby the server no longer takes the risk of falling over if processes start actually using the memory they (m)allocated.
I venture that the increased violet-ish part of the graph explains in part the improved I/O behavior.

OS caching is great.

Dans les 10 derniers jours, deux adresses IP (une tchèque et une chinoise) ont fini par trouver le port en question et s’y sont donné à coeur joie :
User root from [] not allowed because not listed in AllowUsers
Address [] maps to [], but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Failed password for invalid user test from [] port 52960 ssh2


Bien entendu, après une tentative échouée fail2ban bloque l’adresse IP en question pour un bout de temps. Qu’à cela ne tienne, l’indélicat revenait à la charge après le temps imparti.
M’enfin ?! Z’avez rien de mieux à faire ?

• Les attaques dictionnaires sur Sendmail ne sont que trop courantes
  failregex = sm-mta\[[0-9]+\]: [^:]+: \[<HOST>\]: possible SMTP attack: command=AUTH
• Si les spammeurs insistent, Sendmail commence par les ralentir. S’ils insistent trop,
  failregex = sm-mta\[[0-9]+\]: ruleset=check_relay, arg1=[^,]+, arg2=[^,]+, relay=[^ ]+ \[<host>\], reject=421 4\.3\.2 Connection rate limit exceeded\.
• Avec la configuration par défaut de Debian, Suhosin n’a pas (encore ?) produit de faux positif. Armé de cette confiance :
  failregex = suhosin\[[. 0-9]+\]: ALERT - .* \(attacker '<HOST>',
• iptables peut être configuré pour calmer les ardeurs des outils qui ouvrent une pléthore de connexions HTTP. Étape suivante pour les plus pénibles d’entre eux :
  failregex = kernel: \[[. 0-9]+\] HTTP_DoS IN=eth0 OUT= MAC=[^ ]+ SRC=<host> DST=[^ ]+ LEN=[^ ]+ TOS=[^ ]+ PREC=[^ ]+ TTL=[^ ]+ ID=[^ ]+ (DF )?PROTO=TCP SPT=[^ ]+ DPT=80 WINDOW=[^ ]+ RES=[^ ]+ SYN

Autres leçons apprises avec plus ou moins de douleur :

• Il y a un problème de concurrence au démarrage de fail2ban (au moins dans son incarnation 0.8.3), qui peut être évité en plaçant des délais aléatoires comme indiqué dans le bug Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554162.
• Les scripts qui définissent les règles de Firewall sont bien avisés de d’abord arrêter fail2ban, appliquer les règles, puis démarrer fail2ban.

En absence de pré-cablage Ethernet, ils reprennent du service même pour le pingouin_qui_fait_tout.
Malgrès un accès Internet autour des 11 Mbps (votre serviteur regarde ce qu’il peut faire de ce côté là aussi), les sauvegardes sont singulièrement longues.

Voici ce que dit munin, côté trafic :

Rien de bien effrayant, si ce n’est un débit maximal décevant. Le délai aller-retour vers les États-Unis et la France est usuellement suffisamment bas pour qu’une connexion TCP seule arrive à remplir 20 Mbps, même depuis une connexion ADSL.
Sauf que, quand on regarde le comportement du réseau entre le pingouin et le modem ADSL (i.e. principalement le courant porteur), on trouve des latences dignes d’un certain nombre d’aller-retours terre – satellite géostationnaire :

Est-il besoin de préciser que le courant porteur a depuis été remplacé par un câble catégorie 5 ?

La solution brute de décoffrage tient en une commande d’une ligne :


$ iconv -f ISO-8859-15 -t UTF-8 LeFichierAvecLesMauvaisAccents.tex > LeNouveauFichierAvecLesBonsAccents.tex


Sous MacOS, il aura fallu au préalable installer MacPorts et son paquetage libiconv :
$ sudo port install libiconv


Pour rendre la conversion vers UTF-8 plus conviviale, les utilisateurs de Linux pourront utiliser ce script :
#!/bin/bash
shopt -s nocasematch
FILEIN="$1"
FILEOUT=${FILEIN%.tex}"_2.tex"
iconv -f ISO-8859-15 -t UTF-8 -o "$FILEOUT" < "$FILEIN"

et par exemple créer un lanceur sous Gnome. Cela permettra de convertir des fichiers juste en les déplaçant sur l'icône du lanceur.

Les utilisateurs de MacOS / MacPort pourront utiliser ce script (syntaxe légèrement différente, et qui offre le support de plusieurs fichiers en entrée) :
shopt -s nocasematch
for file in "$@"
do
FILEOUT=${file%.tex}"_2.tex"
iconv -f ISO-8859-9 -t UTF-8 "$file" > "$FILEOUT"
done

Il suffit alors de le copier-coller dans Automator pour obtenir une automation comme celle-ci. Elle permettra de convertir des fichiers juste en les glissant sur l’icône.

Il est aussi possible de définir l’action en service MacOS pour l’avoir au bout d’un clic contextuel dans Finder. Ou bien en action Nautilus sous Gnome via le paquetage nautilus-actions, même résultat.

Il y a plus d’une manière de le faire, comme on dit.

Voici un mode d’emploi rapide pour récupérer les photos sous Mac – oui, ça sent le vécu et du copier-coller de mail. Sans garantie aucune, comme d’habitude.

Pour commencer, il faut que tu branches la carte directement sur ton Mac, c’est à dire pas en passant par ton appareil photo mais par un lecteur de carte (genre celui intégré aux Macbooks récents).

Étape suivante, savoir comment il est identifié dans ton système.

Démarre ton « disk utility » (tu peux cliquer sur la loupe en haut à droite, commence à taper « disk » et « disk utility » devrait apparaître).

Ensuite, repère ta carte dans la liste des disques durs à gauche. Chez moi, ça ressemble à ça :

Quand tu as mis ta carte en sourligné (ici mon CANON_DC), clique sur l’icône « Info ». Note bien le « Disk Identifier », chez moi disk1s1:

Ensuite, j’ai fait un test rapide avec ce logiciel (libre) : http://www.cgsecurity.org/wiki/TestDisk_Download qui a l’air de bien faire l’affaire. Télécharge-le en cliquant sur le lien « Mac OS ».

Clique dessus avec ton Safari, ça devrait le décompresser automatiquement et t’ouvrir une fenêtre Finder.

Va dans le répertoire Darwin.

Double-clique sur photorec.

Là, il te demande le disque à récupérer. C’est le « Disk Identifier » de plus haut, mais version « raw » (et sans indication de partition). Pour moi, « rdisk1″, sélectionné avec la flèche de mon clavier qui va vers le bas, puis « Entrée » sur le clavier. La version « par raw » (i.e. disk1, as opposed to rdisk1) a l’air de marcher aussi.

Ensuite, pour « partition table type », choisis « Intel ».

Ensuite, prends la partition « FAT16 >32M » (si ça ne marche pas plus tard, il se peut que tu aies à choisir l’autre option).

Pour le type de partition, choisis « Other ».

Ensuite, choisis « Whole ».

À ce moment là, tu indiques où tu veux sauvegarder les fichiers récupérés.

Je te suggère de choisir « Desktop » (appuies sur Entrée après t’être positionnée sur Desktop), puis confirme en faisant « Y ».

Ensuite… patience, et croise les doigts pour que le nombre de « recovered » en face de « jpg » augmente progressivement. Tu remarqueras que le « Estimated time for achievement » vers le milieu de ton écran descend lentement mais surement vers 0h00m00.

Quand c’est fini, presse « Entrée » (c’est un [Quit] qui t’est proposé).

Te revoilà au menu d’avant : avec la flèche de droite de ton clavier, va sur Quit, Entrée, puis Quit encore une fois.

Utilise ton Finder préféré pour voir le résultat, normalement stocké dans le répertoire « recup_dir.1″.

• Éditer directement les fichiers ics côté serveur, en espérant que caldavd ne le prenne pas mal (risqué ?)
• Interagir avec caldavd en utilisant le protocole idoine (long ?)
• Demander poliment à un client qui met en oeuvre le protocole idoine de se mettre à la tache

La dernière approche a l’avantage d’être potentiellement très rapide en terme de temps de développement, dans un monde où les utilisateurs seraient invité à « programmer » les interactions avec une application essentiellement graphique.

Ce n’est pas le monde de Windows ou même de Linux, où les applications (graphiques) ont tendance à garder leur magie sous le capot. HandBrake / HandBrakeCLI est l’une des plus belles exceptions à la règles dans le monde du transcodage vidéo, mais c’est bien justement une exception.

Sous Mac et en utilisant le client iCal… nul besoin de se plonger dans les arcanes d’AppleScript pour rassembler des bouts de code de ci de là et arriver à ceci en un temps relativement court :

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.