• J’aime ce langage et ça me permet de progresser.
• Je ne suis pas un expert en script bash et le script Python m’autorise plus de souplesse ainsi qu’une maintenance plus aisée.

L’idée principale, outre l’utilisation de la sauvegarde différentielle (et donc la notion de snapshots pour pouvoir « remonter dans le temps ») est de pouvoir utiliser plusieurs media. Ainsi en passant un argument en ligne de commande, il est possible de choisir le medium à utiliser. Il peut être de deux types : local (autre disque dur, appareil USB…) ou sur une machine distante via ssh.

Vous pouvez télécharger le script complet. Pensez à changer l’extension .txt en .py !

Quelques explications sur les constantes du début du programme :

• La variable NICE_LEVEL permet simplement d’indiquer la priorité avec laquelle la copie des données via rsync va être effectuée.
• On définit ensuite la variable DIR_TO_BACKUP qui va préciser quels sont les répertoires à sauvegarder et ceux à éventuellement exclure.
• BACKUP_DEST indique les paramètres de la destination vers laquelle les données seront copiées. Il s’agit d’un dictionnaire contenant un autre dictionnaire Python. Le premier identifie les différents media et le second les paramètres relatifs à ce dernier, qui sont :
  • dir : obligatoire indique le répertoire destination (qui doit exister).
  • server : optionnel, adresse du serveur en cas de copie par ssh.
  • port : optionnel, port du serveur en cas de copie par ssh.
  • login : optionnel, login utilisé pour se connecter au serveur en cas de copie par ssh.

  A noter qu’en cas de copie par ssh, je fais l’hypothèse qu’on utilise une clé ssh pour se connecter et qu’il n’y a donc pas besoin de mot de passe.

• ARCHIVE_NB précise le nombre de sauvegarde à conserver.

Ensuite il y a la fonction backup qui effectue comme son nom l’indique la sauvegarde :

Je n’expliquerai pas ici le détail de la programmation, car il n’y a en principe rien à toucher à ce niveau. Voici les grandes étapes :

• On commence par supprimer l’archive la plus ancienne.
• On effectue un décalage des archives : la 1 devient 2, la 2 devient 3 etc.
• On effectue une copie par hardlink de l’archive 0 vers l’archive 1. Cette technique permet d’éviter une duplication des données et économise beaucoup d’espace. Seules les données inexistantes sont copiées les autres sont des simples liens.
• Enfin on effectue une synchronisation par rsync entre le(s) répertoire(s) à sauvegarder et l’archive 0.

A noter que pour les opérations sur disque (copie, déplacement…), je n’ai pas utilisé les commandes « natives » Python, car dans le cas d’un serveur distant elles ne sont pas utilisables.

L’analyse des paramètres passées en ligne de commande :

Si vous souhaitez ajouter / supprimer des media, il faudra effectuer des modifications dans la partie __main__ du programme ainsi que dans la traditionnelle fonction usage qui indique les arguments qui peuvent être passés à l’application. Je pense que le code parle de lui-même à ce niveau. A noter simplement que j’ai imposé d’être root pour pouvoir exécuter le programme et ainsi copier des dossiers système, mais il n’y a évidemment pas d’obligation…

Ce script peut très certainement être amélioré, n’hésitez pas à me faire part de vos commentaires.

Cela faisait des mois que je cherchais (pas en continu, hein), et la solution est finalement toute simple : il fallait désactiver l’IPv6 dans Firefox :

• Taper about:config dans la barre d’adresse
• Changer ensuite la valeur network.dns.disableIPv6 à True

L’explication doit se trouver dans cet article : « One particular bug that has appeared exists not in Mozilla, but in IPv6-capable DNS servers: an IPv4 address may be returned when an IPv6 address is requested. It is possible for Mozilla to recover from this misinformation, but a significant delay is introduced. »

Donc en gros, certains serveurs DNS renvoient une adresse type IPv4 quand une adresse IPv6 est demandée et cela introduit un délai de conversion. Ceci expliquerait également que je n’ai pas le problème chez moi, puisque j’ai un fournisseur d’accès différent et donc un serveur DNS autre.

Ainsi pour une utilisation en production, on le couple à un serveur http, par exemple le très célèbre Apache. Pour ce faire on va utiliser l’interface standard Python : WSGI (Web Server Gateway Interface). Un exemple de configuration est fourni sur la documentation officielle de Django.

Cependant il existe un moyen à mon avis plus élégant de parvenir au but recherché : l’utilisation de gunicorn en tant que proxy. Je n’ai pas eu encore l’occasion de le tester autrement qu’en local, mais il s’avère très prometteur en terme de rapidité. De plus, une fois gunicorn installé (très simple puisqu’il s’agit d’un package Python), la configuration est vraiment aisée.
Plutôt que de paraphraser, je vous renvoie vers un article très bien fait.

Important : il faut s’assurer que les chemins vers l’application Django définis dans la configuration d’Apache sont bien accessibles par l’utilisateur qui exécute Apache.

Je vous ai sélectionné deux excellents tutoriels qui vous permettront de bien débuter en Python (et en français, s’il vous plait !) :

• Tutoriel général sur le langage Python : très sobre (voir austère) dans sa présentation il vous prend par la main et vous explique comment utiliser ce formidable langage depuis l’affichage d’une chaîne de caractères jusqu’au concept des classes.

• Tutoriel sur PyGTK : de nombreux exemples avec des explications très fournies sur l’art et la manière de créer des applications graphiques en utilisant PyGTK (avec gtk.Builder, successeur de libglade), GTK étant l’acronyme de GIMP Tool Kit.

Dokuwiki est comme son nom l’indique un wiki et il présente à mes yeux les avantages suivants :

• Léger avec une syntaxe intuitive.
• Moteur de recherche intégré.
• Absence de base de données : les données sont stockées dans des fichiers et sont lisibles avec n’importe quel éditeur de texte. Ce qui veut dire que la maintenance du wiki est très aisée (lors de sa mise à jour, en cas de migration sur un autre serveur). De plus il est également très facile de faire des sauvegardes ou des réplicats.
• Possibilité de créer une arborescence de pages en utilisant des catégories. La gestion est très souple puisqu’il suffit de créer une page nommée ma_categorie:ma_page pour que la catégorie ma_categorie soit créée et que la page ma_page y soit placée.
• Possibilité de gérer des droits d’accès, applicables par catégorie.
• Installation simple.
• Nombreux plugins disponibles.

Personnellement je l’ai adopté pour plusieurs wiki que j’administre mais également dans le cadre d’une utilisation plus personnelle, pour la gestion de mes notes, de ma documentation quelle qu’elle soit (informatique ou autre). En effet l’utilisation de fichiers sur son disque dur devient vite un enfer. Avec Dokuwiki comme gestionnaire de documentation vous pouvez :

• Retrouver facilement vos notes grâce au moteur de recherche intégré.
• Insérer des liens internes (entre vos pages) et externes. Une réflexion intéressante à ce sujet est qu’il peut dans une certaine mesure remplacer un gestionnaire de marque-pages (ceci est valable pour n’importe quel wiki). En effet si ces derniers sont pratiques pour retourner rapidement sur un site ils s’avèrent très peu adaptés pour gérer des liens qui font office de documentation. En les insérant dans votre wiki vous pouvez y associer une explication, un descriptif et ensuite les retrouver via le moteur de recherche.
• Historique des modifications des pages : toujours très utile dans le cadre de gestion d’une documentation.

Bref terminé les fichiers dans tous les sens qu’on ne retrouve / consulte jamais, sans aucun lien entre eux. J’ai fait de Dokuwiki mon outil central depuis maintenant des mois et c’est le meilleur système que j’ai trouvé jusqu’à présent.

Je suis à l’origine de la création d’OpenAguila, je suis donc assez mal placé pour juger de ses qualités et défauts, cependant d’après les retours des utilisateurs, le logiciel est apprécié pour sa simplicité ainsi que son pragmatisme concernant son utilisation. Une fois la philosophie de fonctionnement acquise, on est rapidement opérationnel. Ces qualités proviennent du fait qu’OpenAguila a été créé en partenariat étroit avec un chef d’entreprise, ce n’est donc pas un logiciel fait par des informaticiens pour des informaticiens.

OpenAguila a cependant aussi certains défauts criants comme la lourdeur d’utilisation de certains modules (approvisionnement, intervention), l’impossibilité de paramétrer facilement des éditions PDF (il faut rentrer dans le code XSL), le manque d’interfaces vers l’extérieur (import / export). De plus, sa réalisation a débuté à la fin des années 90, sa conception technique est vieillissante, ce qui rend la maintenance / les évolutions délicates.

Pour toutes ces raisons j’ai décidé une refonte complète de l’application. Cette refonte sera essentiellement technique (passage du langage JAVA à Python), la philosophie dont je parlais plus haut sera bien évidemment conservée, tout en essayant de gommer les défauts fonctionnels.

Pourquoi ce changement radical ?

• Le framework utilisé par OpenAguila est spécifique (fin des années 90, il n’y avait pas les outils web actuels), il faut entièrement le revoir pour pouvoir effectuer par la suite facilement des évolutions.
• Je me suis lassé de l’utilisation de Java que je trouve trop lourd / rigide. Lors de ma participation à un autre projet j’ai eu l’occasion de découvrir le langage Python ainsi que le framework web Django. J’en suis tombé amoureux…

Dis, OpenAguila2 va être livré quand ?

La réponse habituelle dans le monde des logiciels libres : « quand on aura fini ». Le travail est en effet gigantesque, le nombre de participants va être primordial. Pour l’instant quelques personnes se sont manifestées pour apporter de l’aide au projet (développement, tests, documentation), mais plus on est de fous, plus on rit. La compétence qui nous manque est un designer web, qui nous fasse des jolies pages (qui a dit comme pour tous les projets ?).

Si vous avez envie de participer à un projet libre, quelque soit vos compétences, vous êtes le bienvenu .

L’installation de Conky est très simple, elle se fait par votre gestionnaire de paquets favori. Pour le mettre au démarrage de votre gestionnaire de fenêtres, il faut éditer votre fichier $HOME/.xinitrc et placer tout au début par exemple :

(sleep 10 && conky) &

On ordonne par là de lancer conky en tâche de fond au bout de 10 secondes.
Pourquoi en tâche de fond ? Si vous ne le faites pas, la suite de votre .xinitrc ne va pas s’exécuter, donc autant dire que votre gestionnaire de fenêtre n’apparaîtra pas.
Pourquoi un délai de 10 secondes ? Ce délai dépend de votre configuration, mais il est nécessaire d’en mettre un sinon l’affichage de votre conky risque d’être écrasé par celui de votre gestionnaire de fenêtres.

vi ~/.gtkrc-2.0
style "xfdesktop-icon-view" {
XfdesktopIconView::label-alpha = 0
fg[NORMAL] = "#ffffff"
fg[SELECTED] = "#17B2FF"
fg[ACTIVE] = "#17B2FF"
}
widget_class "*XfdesktopIconView*" style "xfdesktop-icon-view


Voilà

Avec ArchLinux le procédé est très simple, il suffit d’éditer le fichier /etc/pacman.conf et d’ajouter le paquet à la ligne :

IgnorePkg = mon_paquet_a_ignorer

En fait cela ne fonctionnait pas avec Enlightenment alors qu’il n’y avait aucun problème avec Openbox. Bon c’était déjà ça, cela signifiait que ce n’était pas dû à Archlinux lui-même… En regardant dans les logs, je voyais que le périphérique était bien détecté. J’arrivais d’ailleurs à le faire manuellement en utilisant le compte super-utilisateur. Mais lorsque je cliquais sur l’icône de mon périphérique, j’avais invariablement une erreur du type PermissionDeniedByPolicy mount-removable no.
En cherchant sur Internet j’ai constaté que le problème venait de HAL (Hardware Abstraction Layer). Finalement je suis tombé sur cet article.
En observant mon fichier ~/.xinitrc, je me suis rendu compte que Enlightenment était lancé simplement comme cela :

exec enlightenment_start

D’après l’article cité précédemment, il faut le lancer de cette manière :

exec ck-launch-session enlightenment_start

La raison est (je cite) : « La dernière mise à jour de HAL a le support de PolicyKit et ConsoleKit activé, plus concrètement, les droits de montage/démontage, arrêt/redémarrage, mise en veille/hibernation sont donnés par défaut au propriétaire de la session (celui qui est connecté) mais il faut pour cela démarrer ConsoleKit avec votre session graphique. »