Effraie.org héberge pas mal de sites, et la question des sauvegardes est devenue cruciale.
Bien sur, je pourrais renvoyer les utilisateur-ices à leur responsabilités, et leur demander de faire leurs propres sauvegardes. Cela dit, rien ne dit qu'elles/ils les fassent régulièrement, ni qu'ils sachent comment sauvegarder une base de données.

Je me suis donc penché sur la question, et j'ai amélioré mon rsync quotidien pour obtenir un système qui me convient mieux,

Pour assurer que les données seront à l'abri en cas de crash des disques durs internes, mon répertoire backups/ est situé sur un disque usb externe. Prochainement, je cherche également à automatiser une sauvegarde de ce répertoire sur un serveur distant

Sauvegardes des bases de données

J'utilise, suivant les conseils avisé d'un copain, le script autoMYSQLBackup.sh qu'on trouve ici. Après configuration de quelques variables, le script est opérationnel, et il ne vous reste qu'a le lier dans /etc/cron.daily/ pour obtenir une sauvegarde automatisée de chacune de vos bases. Le script conserve les backups des derniers 7 jours, une par semaine pendant un mois, et une par mois indéfiniment.
Au final, cela me permet de conserver une trace des données sur le long terme, sans pour autant user une espace disque démesuré, dans backups/sql.

Sauvegardes des données:

Pendant longtemps, je me suis contenté d'utiliser rsync pour sauvegarder les données du serveur. Cependant, je souhaitais bénéficier, comme pour les bases de données, de la possibilité de restaurer une sauvegarde plus ancienne. Pour cela, j'ai utilisé des outils standards, rsync, cp, rm, date, find et crontab.

Le fonctionnement est simple:

sauvegarde principale:

Chaque nuit, à 2h30, je sauvegarde l'ensemble des données que je veux pouvoir restaurer dans un répertoire backups/main, avec le "mini script" suivant, qui synchronise la racine du serveur avec ma sauvegarde:

#!/bin/sh
rsync -azh  --exclude=/pattern/à/ne/pas/sauver --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/sys   --delete-after --delete-excluded --stats / /chemin/vers/backups/main

et cette ligne dans la crontab de root:

30 02  *  *  * /chemin/vers/le/script/main_backup 2>&1 | mail votre@email.tld -s "[Rsync] rapport du `date +%A\ %d\ %B\ %Y`"

Je reçois ainsi chaque jour un rapport statistique sur la synchronisation, de cette forme:

Number of files: 208552
Number of files transferred: 1038
Total file size: 8.23G bytes
Total transferred file size: 354.84M bytes
Literal data: 354.86M bytes
Matched data: 0 bytes
File list size: 6230145
File list generation time: 98.647 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 70.71M
Total bytes received: 24.00K

sent 70.71M bytes  received 24.00K bytes  344.18K bytes/sec
total size is 8.23G  speedup is 116.42

En cas de problème, le mail contient la sortie d'erreur de la commande.

Journalisation des sauvegardes

Pour pouvoir restaurer des sauvegardes plus anciennes, ou des fichiers effacés il y a plusieurs jours sur le serveur (et donc absent de backups/main), j'utilise trois petits scripts simplistes, qui, associés à une ligne adéquate dans la crontab de root, me permettent de conserver l'ensemble des sauvegardes des 7 derniers jours, une sauvegarde par semaine pendant un mois, et une sauvegarde par mois pendant 6 mois.

Note ajoutée à la suite de quiproquo dans les commentaires
Le systéme de journalisation/rotation des backups utilise l'option -l de cp, pour créer des hardlinks au lieu de recopier les fichiers, dans tt les cas ou le fichier n'a pas été modifié. C'est le moyen de n'utiliser que l'espace disque minimum requis. Compresser les données dans une archive ferait perdre cet avantage, et utiliserait, finalement, plus d'espace disque.

Voici les scripts et les entrées dans la crontab qui vont avec:

daily_backup

le script:

#!/bin/sh
find /chemin/vers/backups/timed/daily/* -ctime +7 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /chemin/vers/backups/timed/daily/`date +%F` 2> /dev/null;

L'entrée dans la crontab:

30 03  *  *  * /home/effraie/scripts/daily_backup

weekly_backup

le script:

#!/bin/sh
find /chemin/vers/backups/timed/weekly/* -ctime +33 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /chemin/vers/backups/timed/weekly/`date +%U_%F` 2> /dev/null;

L'entrée dans la crontab:

40 03  *  *  0 /home/effraie/scripts/weekly_backup

monthly_backup

Le script:

#!/bin/sh
find /chemin/vers/backups/timed/monthly/* -ctime +183 -exec rm -rf {} \;
cp -al /chemin/vers/backups/main /mnt/usb-data/backups/timed/monthly/`date +%m-%Y` 2> /dev/null;

L'entrée dans la crontab:

50 03  1  *  * /home/effraie/scripts/monthly_backup

Avec ça, je pense être habillé pour l'hiver! Cela dit, toute suggestion d'amélioration est la bienvenue.

Heureux possesseur d'un appareil reflex numérique, et passionné de photographie, voila quelques temps que je me suis penché sur la meilleur façon d'organiser mon flux de travail sous linux.

En effet, bien que Photoshop soit l'application propriétaire réputée la plus réclamée par les utilisateurs de Linux, l'OS au pingouin est en en réalité très bien équipé pour faire face a un flux de photographie numérique avancé.

Dans ce billet, je vais tenter de présenter un flux de travail pour la photographie numérique, entièrement sous Ubuntu. Certains logiciels présentés ne sont pas libres, mais je présenterai les alternatives libres existantes.

Développer ses RAW

Si la plupart des photographes sont très satisfaits des images JPEG que produit leur appareil photo numérique, le photographe exigeant voudra maîtriser lui même le développement de ses RAW. Pour ceux qui ne le saurait pas, le RAW (codé sur 16 bits (enfin, c'est plus compliqué que ça, en fait... mais bon)) est un format qui conserve l'ensemble des données brutes captées... par le capteur de l'appareil photo, tandis que le JPEG (codé sur 8 bits) est un format déjà traité par l'appareil, au niveau de la couleur, de la balance des blancs, du contraste...

Sur la plupart des appareils photo numérique haut de gamme (récents) et sur tout les reflex numériques, il est possible de choisir le format RAW plutôt que JPEG pour l'enregistrement de ses images, pour conserver un maximum de données et se réserver une marge de manœuvre importante au moment du développement. Si vous souhaitez faire de la photo d'un point de vue expert, professionnel, artistique, ou passionné, c'est le format qu'il vous faut.

Attention! Le format RAW a de nombreux avantages, mais il est également plus contraignant. Les fichiers sont très volumineux, et exige un traitement relativement important avant d'être exploitable d'aucune façon.

Pour développer mes RAW sous Ubuntu, j'utilise un logiciel (propriétaire) d'excellente facture, nommé Bibble. Il s'agit d'un des premier déRAWtiseurs historique, et il produit d'excellents résultats. Disponible sur Linux, mais aussi sur MacOS et Windows, il s'agit d'un logiciel en QT véritablement multiplateforme. C'est à mon goût le meilleur choix possible d'un point de vue technique. Sachez cependant que ce logiciel est payant, et qu'il permet une période d'essai d'un mois.

cliquez sur l'image pour voir la capture en plein écran:



Il faut noter qu'il y a plusieurs alternatives à Bibble sous Linux:

• LightZone: un autre logiciel propriétaire, gratuit cette fois ci (mais payant sous MacOS et Windows). Il a de nombreux supporters, mais la version linux est la 2.3 quand la version "officielle" est la 3, et il semble que notre plateforme ne soit pas vraiment considérée comme égale aux autres... Cependant, entre sa gratuité et sa gestion originale des zones et des filtres, il est utile de l'avoir sur un coin de disque dur (ici pour la version linux)

• ufRAW est certainement la solution libre la plus abouti pour traiter des RAW. Il existe en version autonome ou en plugin pour the GIMP. Néanmoins, il est a mon goût encore trop loin derrière (en particulier ses interfaces graphiques...) pour suffire  a une pratique quasi quotidienne  du format RAW.

• Citons également, en vrac parce que je les connais moins, et qu'il me semble qu'ils sont moins aboutis, dcRAW (plugin GIMP), RAWtherapee, et RAWstudio. N'oublions pas BlueMarrine un projet encore en développement, mais prometteur.

Tous ces logiciels s'installe trés simplement sous Ubuntu, je ne m'étends pas.

Retoucher ses images

Dans ce domaine, c'est The GIMP le logiciel roi:

Plutôt que de vous répéter des choses que vous savez déjà, je vous donne plutôt quelques liens qui explique comment un photographe peu tirer parti de GIMP:

• #tutorials/photos une série de tutoriels orientés photo,
• Traitement par zone et gestion 16 bits sous gimp Très complet, très technique: une mine,
• Groking the GIMP en français: la bible de gimp,
• Masques sous GIMP

N'oubliez pas, cependant, qu'il existe Krita, intégré a l'environnement KDE, qui a les même objectifs que la GIMP. Notons aussi que Gimp à quelques limitations importantes:  pas de support 16 bits, pas de gestion des couleurs, pas de calques d'ajustement, pas de groupes de calques...

Gérer sa bibliothèque d'images

Dans ce domaine, les logiciels performants sous Ubuntu sont légion! La plupart d'entre eux permettent de trier, classer, tagger, archiver... vos images, même en très grand nombre. Ils permettent également d'effectuer un certains nombres de retouches "basiques", les fonctionnalités variants d'une application à l'autre: rotation, recadrage, courbes, export vers le web ou un media externe...

Personnellement, j'utilise F-spot, fournit par défaut dans Ubuntu. Il permet une gestion très efficace d'une collection trés importante, des fonctionnalités de retouches avancées, la gestion du versionnage des images, l'export vers gallery, flickr, une galerie web statique, un cd...

Dans ce domaine, certains prétendent que Digikam (intégré a Kubuntu et a l'environnement KDE) est meilleur. Ce n'est pas mon avis, mais ce doit être une affaire de goût. Dans ce domaine, il faut aussi citer Gthumb (de base dans Ubuntu) et Jbrout. (j'en oublie sans doute)

Créer un panoramique

Pour cela, un logiciel sort du lot: il s'agit de Hugin. Un peu complexe à mettre en œuvre, il est rudement efficace! Je vous suggère de vous reporter à cette page de la doc pour en savoir plus.

Créer des images HDR

le HDR est une technique relativement récente en photo numérique, qui produit des résultats impressionnants. Je cite wikipedia:

L'imagerie à grande gamme dynamique (High dynamic range imaging ou HDRI) regroupe un ensemble de techniques numériques permettant d'obtenir une grande plage dynamique dans une image. Son intérêt est de pouvoir représenter ou de mémoriser des niveaux d'intensités lumineuses très différents dans une même image. Cette technique s'effectue en permettant d'attribuer plus de valeurs à un même pixel. D'abord développée pour les images générées par ordinateur, la technique s'est ensuite adaptée à la photographie numérique.

Un exemple de HDR:


image de Nattfodd sous licence Creative Commons CC BY-NC

Pour ce type de traitement sous Ubuntu, il existe une interface graphique conviviale, nommée QTpfsgui
Ce logiciel est disponible sur un dépôt tiers, et il me semble qu'il sera intégré a Ubuntu pour la Gutsy Gibbon. Vous pouvez vous reporter à la documentation pour plus d'information quand à son utilisation et son installation.

Calibration et gestion de la couleur

J'ai gardé ce point pour la fin, car c'est encore aujourd'hui un point noir pour le photographe sous linux.

Si votre écran est d'une qualité correcte, et que vous n'êtes pas trop exigeant, vous pouvez vous en passer, et vous ne savez peut être même pas de quoi il s'agit. Par contre, si vous souhaitez maitriser toute votre chaine photographique, vous savez déjà ce que sont les espaces de couleurs et les profils couleurs des différents matériels.

Sans entrer dans les détails ennuyeux, sachez simplement que chaque appareil traite le rendu des couleur d'une façon qui lui est propre, et que pour obtenir sur papier ce que l'on voit a l'écran, il faut avoir la maitrise du profil couleur de son écran, de son imprimante, et d'une façon générale, de tout les éléments matériels du flux. Pour un écran, il s'agit de le calibrer (régler) de façon a ce qu'il affiche les blanc vraiment blancs, les noirs vraiment noirs, et d'une façon générale, les couleurs d'une façon juste, et pas "chaude" ou "flatteuse", comme pour un jeux vidéo. Sans quoi, sur l'image que vous aviez peaufiné pour obtenir un beau rouge Ferrari sur les fleurs de tatie george, les roses seront oranges... et vous serez vert.

Bibble (par exemple) gère parfaitement les profils, et c'est le cas de nombreuses applications sous ubuntu. Le problème n'est pas là.

Je m'explique: Une bonne calibration ne peut que difficilement être faite a l'oeil, et nécessite l'usage d'une sonde colorimétrique, qui se pose sur l'écran, se branche sur l'ordinateur,  et permet de comparer des valeurs de couleurs avec celles que renvoie l'écran. À l'issue de la procédure, vous obtenez un "profil" de votre écran, qui vous permet de maîtriser la colorimétrie de votre écran. En utilisant ce profil en conjonction avec celui de votre imprimante, ou de votre labo photo, vous êtes assuré d'avoir une bonne gestion des couleurs, et vos roses seront rouge Ferrari.

Malheureusement, la plupart des sondes ne sont pas compatibles avec Ubuntu (et Linux en général), et les logiciels qui vont avec sont exclusivement réservés a MacOS et Windows.

Cette page explique comment calibrer son écran sous linux, sans matériel supplémentaire, et quand on a la chance d'avoir un écran qui peut de régler d'un point de vue matériel, et pas seulement logiciel.

Il existe quelques utilitaires, tel que Monica, pour vous aider a régler le point noir et le Gamma de votre écran, Argyll pour créer un profil ICC avec l'une des rares sondes qui soient compatibles avec le pingouin, et enfin Xcalib a charger ce profil, pour l'utiliser. Sachez cependant que c'est loin d'être un processus facile...

Une solution alternative serait d'utiliser un windows virtualisé (avec vmware ou virtualbox?) ou bien déporté avec VNC pour créer sous windows un profil valide pour Xorg... c'est tordu, mais ça devrait marcher. Si quelqu'un a tenté cette expérience, je suis curieux d'en connaître le résultat. (visiblement, ça marche!)

Edit: Stéphan Peccini à écrit un super article en français sur la calibration de son écran sous Linux.

Pour finir

Si tout ce travail ne vous à pas découragé, je vous invite a créer un photoblog avec l'excellent logiciel libre PixelPost pour montrer vos images au monde entier. et au passage, je ne résiste pas à l'envie de vous montrer le mien.

J'héberge mon mail à la maison, sur mon serveur Ubuntu Dapper^[1]. Ça a pas mal d'avantages que je ne détaillerais pas ici.

Jusqu'ici, je me contentais de quelques règles bien senties dans le main.cf de Postfix^[2] pour tenter d'éradiquer le spam. (merci à Yop pour ça, d'ailleurs, ce type est précieux.)

Malgré tout, mon Thunderbird avait la lourde tàche d'éliminer les quelques spams qui passaient tout de même. Et ces derniers temps, il commençait a être débordé... et les modérateurs de mes listes de diffusions aussi!

J'ai donc décidé de prendre le taureau par les cornes, et j'ai mis en place du greylisting ^[3]

Le principes et simple: chaque mail qui arrive est d'abord refusé par postfix, qui stocke dans une base de donnée l'adresse IP de l'expéditeur, l'adresse email de l'expéditeur, et l'adresse email du destinataire. Tout serveur SMTP "réglo" va tenter plus tard un nouvel envoi, qui sera alors accepté. Les spammeurs, eux, majoritairement, ne feront pas de nouvel envoi.

Bien sur, il y a des inconvénients:

• Un spammeur "malin" fera, lui, un deuxième envoie, et sera donc accepté. Il y en a peu, parait-il. Et une bonne règle RBL^[4] limite drastiquement ce risque...
• Un délai de latence pour la réception des email va apparaître... heureusement, une fois une première quarantaine effectuée, il disparait. Et le paquet debian postgrey fait automatiquement du whitelisting au bout de 5 envois honnêtes. A moyen terme, donc, c'est un problème mineur.

Cette manipulation n'est pas anodine! néanmoins, si vous avez su installer et configurer Postfix, vous devriez vous en tirer

Pour mettre en place cette solution sous Debian/ubuntu, c'est trés simple:

# apt-get install postgrey

Ensuite, il faut rajouter dans /etc/postfix/main.cf, dans la section smtpd_recipient_restrictions =

check_policy_service inet:127.0.0.1:60000

Pour la règle RBL, vous pouvez ajouter, dans la même section:

reject_rbl_client sbl-xbl.spamhaus.org

Redémarrez ensuite postfix, et voila!

C'est très efficace: depuis 36 heures 11 jours que c'est en place, je n'ai pas reçu un seul spam.