git-annex: git vitaminé pour "drop box like" libre

Cela fait désormais un sacré moment que j’ai publié ma revue des solutions de synchronisation. Comme souligné par un commentaire récent, un petit retour est nécessaire.

J’utilise git pour coder. J’utilise aussi git pour synchroniser mes fichiers grâce à mon serveur auto-hébergé. Git, c’est bon, il faut en manger matin, midi et soir.
L’idée de dvcs-autosync était bonne, mais il y avait quelques bugs génants et je ne suis pas allé voir les forks. Alors, je pousse mes commits à la main. Ce n’est pas si fastidieux. A part ce point, j’ai cependant un problème. L’un de mes dépôts est dédié à synchroniser des pdf, beaucoup de pdf, environ 500, ce qui représente plusieurs Go. Ajouter/synchroniser de nouveaux fichiers ne pose pas de problèmes, mais si je devais synchroniser à un nouvel endroit, ce serait… interminable.

Il existe un projet kickstarter que je trouve génial. Je ne comprend pas pourquoi peu de gens en parle d’ailleurs. Un joli contre-exemple à ce qui est dit dans cet article de linuxfr. Grâce à l’argent des donateur, l’auteur travaille sur le projet depuis plus de 200 jours et pour les petits tests que j’ai mené, je trouve que le travail est excellent. Si vous vous demandez pourquoi sparkleshare, dvcs-autosync ou sharebox ne conviennent pas, je vous laisse lire son argumentation. Ca fait plusieurs mois que je surveille ce projet, et j’ai décidé de m’y mettre sérieusement. D’où le présent billet.

Quel est le principe de git annex pour gérer les gros fichiers ? Très simple. Plutôt que de synchroniser le fichier lui-même, on synchroniser un lien symbolique pointant vers le fichier. Ainsi, lorsqu’on "pull" le dépôt, on récupère l’arborescence des fichiers qui sont ces liens. Ceci permet de les réorganiser par exemple, sans avoir à télécharger les fichiers. C’est un gain impressionnant. Si on veut lire le fichier, il suffit de télécharger ce fichier spécifiquement. Il peut d’ailleurs être retiré par la suite une fois que les modifications ont été poussée. Ainsi, on gagne de l’espace disque.

Voici en quelque ligne, un usage de base :
git init # crée le dépôt
git annex init "my laptop" # crée une instance annex
git annex add big_file.dat # ajoute un fichier à annex
git ci -a # commit

Maintenant, on clone le dépôt que nous venons de créer :
git clone …
# là, les fichiers ne sont pas lisibles
cat big_file.dat
# mais on peut les télécharger
git annex get big_file.dat
# et les lire !
cat big_file.dat
# et on peut supprimer le contenu en gardant le lien symbolique
git annex drop big_file.dat

Git annex est donc conçu pour des gros fichiers, de type photos, musiques, vidéos, données… et il peut être utilisé pour

• Synchroniser deux machines.
• Partager avec des amis. (jabber inside)
• ou archiver.

Le développeur est Joey Heiss, j’ai déjà parlé ici de ces logiciels (github-backup et ikiwiki).

Et si github fermait ?

Que feriez-vous ?

Le titre est provocateur. Pour ceux qui n’utilisent pas github, je me doute que vous ne ferez rien. Quoique…

Comme vous le savez, github est un service de gestion de projet utilisant git. Comme tout service administré par un tiers (qu’il soit libre ou non, ça ne change rien), sa pérennité n’est pas assurée.

Contrairement à beaucoup de services du "cloud", l’utilisation de github n’est pas le mal absolu, car étant basé sur un gestionnaire de version décentralisé, chaque contributeur possède une copie locale avec l’historique du code.
Théoriquement, si github fermait, nous devrions pouvoir tout reconstituer avec ce que nous avons sur nos disques.

Dans la pratique, s’assurer d’avoir des copies à jour de ce qui nous intéresse, ce n’est pas du luxe. Joey Hess, l’un des développeurs dont j’apprécie le travail, a développé github-backup.
Le logiciel est codé en Haskell et publié en GPL. L’utilisation est triviale, il suffit de lire le README.

Le principale avantage de ce logiciel est de récupérer les tickets ainsi que les forks (aspect de récursivité). C’est donc une sauvegarde complète. La limite provient de l’API de github, qui limite les requêtes. Il faut donc lancer parfois plusieurs fois le script, surtout lors de la première copie. Ensuite, naturellement, ça fonctionne en "diff".

Pour ma part, j’ai mis ce code python en trois minutes et lancé en tâche cron sur mon serveur. a, b et c sont bien entendu des dépôts fictifs.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Author: Francois Boulogne
# License: GPLv2+

import os
from subprocess import call
import random

repos = ['a',
        'b',
        'c',
        ]
random.shuffle(repos)

backup_dir = os.path.expanduser('~/github_backup')

soft = 'github-backup'

for repo in repos:
    backup_path = os.path.join(backup_dir, repo)
    os.makedirs(backup_path, exist_ok=True)
    os.chdir(backup_path)
    call([soft, repo])

En quelques mots, le fonctionnement. Je mélange ma liste de dépôts. De cette manière, je ne commence jamais par le même dépôt, et j’évite qu’un dépôt sature le compteur de l’API de github et empêche ainsi la sauvegarde d’autres dépôts. Pour le reste, je crée des répertoires et je me place dedans pour synchroniser. Il faudrait que je maintienne un log pour être propre, avec le sortie de la commande.

On pourrait ensuite mettre en place une interface web là-dessus comme gitweb pour avoir un miroir visible par d’autres.

A titre personnel, je synchronise mon espace, mais aussi les projets que j’apprécie et qui sont hébergés sur github. Ce sont parfois de petits codes qui ne font pas la une de linuxfr, mais j’y accorde beaucoup d’importance.

Pour ce qui est de la question original, j’essaie de me poser systématiquement la question sur ce qui m’environne. Et si ça disparaissait ? Comment serait-je affecté ? Comment puis-je l’anticiper pour que ça se passe au mieux ?

Des logiciels pour être efficace

Depuis que j’utilise des logiciels libres, je me suis tourné vers la programmation mais c’est aussi parce que je voulais faire cette apprentissage que je suis passé à GNU/Linux. De cette expérience, je tire différents savoirs nouveaux et au final, je me demande si je n’ai pas appris d’avantage concernant les éléments périphériques que sur la programmation elle-même… Je fais cette introduction pour dire que l’efficacité sur une machine, telle que je la conçois, je la tire de cette expérience et des logiciels qui y sont liés.

Je vais donc faire une liste des logiciels qui me semblent décupler mon efficacité mais aussi mon plaisir à travailler.

ZSH

L’un de mes premiers apprentissages, lorsque je suis passé à un OS libre, fût d’apprendre à utiliser la console. Comme je pense la majorité des gens, j’ai commencé par Bash. Bash, c’est bien, mais c’est peu palpitant. J’ai lu beaucoup d’avis positifs sur ZSH alors j’ai testé et aujourd’hui, je ne peux plus me passer de

• sa complétion

•  l’usage de jokers récursifs

GNU-Screen/Tmux

Nous voilà doté d’un shell digne de ce nom, passons maintenant à la dimension du dessus, l’organisation du terminal.
Ouvrir des fenêtres à chaque fois que l’on a besoin d’un prompt, c’est rapidement fatiguant. Des multiplexeurs de terminaux comme screen ou Tmux (fonctionnalités très proche, l’un ou l’autre fait l’affaire généralement) nous facilitent la vie. Je le considère pour ma part comme étant un gestionnaire de fenêtre, tout aussi important que d’avoir Gnome ou openbox. Je peux ainsi avoir un équivalent de bureaux virtuels, que je peux nommer pour me repérer. Par exemple, une fenêtre avec le fichier de conf, une avec le code, et une autre pour parcourir les répertoires où sont écrites les données. D’autres arguments dans la suite.
Avec Screen, je n’accorde plus vraiment d’importance à l’émulateur de terminal parce que je n’utilise aucune de ses fonctionnalité, si ce n’est une seule : qu’il puisse apparaître en plein écran et disparaître par l’action d’une touche (console top/down). J’utilise tilda, mais ça pourrait être autre chose.

VIM

Editer des fichiers, en console, c’est pour le moins fréquent. Dès mes premiers pas, j’ai voulu apprendre autre chose que nano. Pour couper court au débat, je n’ai jamais utilisé emacs et avec vim, je suis certain qu’il sera disponible sur 99,99% des machines que je rencontrerai. Il a une large panoplie de greffons, les possibilités sont infinies.
Ca permet de faire de l’adminsys, de la rédaction, du développement…

SSH

SSH est juste un outil incontournable. Bien sûr, ça permet de joindre une machine distante, mais pas que. C’est aussi le moyen d’envoyer des fichiers, d’établir un proxy ou de passer à travers un réseau NATé. C’est rapide et sécurisé.
Lorsqu’on utilise SSH, on apprécie de savoir utiliser Screen ou Tmux.

• si la connexion lâche, screen se détache et la mise à jour critique en cours n’est pas plantée au milieu, et là, on est heureux.

• si on a travaillé sur une machine localement et qu’on souhaite s’y reconnecter par le réseau plus tard, on peut récupérer la session screen restée ouverte. Autrement dit, je retrouve exactement le même environnement qu’en local.

Git

Ca, c’est un gestionnaire de version qu’on ne présente plus. Je gère mes projets avec, mais aussi ma synchronisation de fichiers et un wiki comme ça (j’en ai parlé ici déjà). Je ne connais même pas le 1/100e de ses possibilités et il m’est néanmoins indispensable.

Python

J’ai codé dans un certain nombre de langage. Je ne peux pas dire que je les maîtrise (même python) car je ne suis pas un développeur expert par manque de temps plus que d’envie. Après avoir codé pendant un certain temps en bash mes scripts systèmes, j’ai découvert Python, et aujourd’hui c’est mon couteau suisse :

• scripts systèmes

• code scientifique

• petits utilitaires

La syntaxe est claire, ce qui fait du code maintenable. Les bibliothèques sont très variées ce qui permet de couvrir un grand nombre de besoin. Enfin, c’est suffisamment haut niveau pour écrire rapidement un code fonctionnel et c’est important ; on n’est rarement là pour faire des exercices de style. En clair, investir dans un langage polyvalent comme celui-ci, ça permet de se sortir de problèmes lourds rapidement et sans trop d’effort.

Conclusion

Ces outils, je les utilise tous les jours, sans exception. Il n’y a que pour le courriel et le web où je suis resté sur des outils "populaires" avec Firefox et Thunderbird.

Le dénominateur commun à tous ces outils :

• c’est austère. Oui, mais c’est épuré, et ça a l’avantage que le contenant ne distrait pas du contenu.

• ça demande un apprentissage qui peut être parfois long. En contre-partie, ce sont des outils que l’on verra encore probablement pendant quelques décennies.

 

CV sans maux avec Latex : biblio et traduction

Sans surprise pour celles et ceux qui me suivent, je fais mon CV avec latex, depuis un sacré paquet d’année d’ailleurs. Un CV, ça évolue vite et dans certains cas, il faut en faire des versions spécifiques pour l’occasion.

Dans mon cas, j’ai deux besoins lourds à gérer :

1. la liste des publications
2. la traduction

Commençons par la liste des publications. A maintenir, c’est pesant. Il faut que ce soit correct, bien formaté, à jour, dans l’ordre… et le travail doit être fait à plusieurs endroits comme une page perso. Utiliser bibtex pour ça, c’est donc plutôt malin sauf que dans le CV, on veut séparer les types de publications. Pour cela, je vous conseille de prendre exemple sur Matthew Miller. Puisque j’ai réutilisé ce qu’il a fait, inutile que je le répète. Il utilise le paquet multibib.
On utilise ainsi la même pas de donnée que pour la page web, donc gain de temps non négligeable. On peut vérifier qu’on n’a rien oublié avec un grep sur le fichier bibtex.

La traduction maintenant. La méthode manuelle consistant à copier et traduire est selon moi à bannir. Très vite, cela va mener à deux versions divergentes qu’on ne parviendra plus à rapprocher. J’utilise po4a que j’ai déjà encensé sur ce blog. Je commence par un fichier po4a.cfg

[po4a_langs] fr
 [po4a_paths] po/i18n.pot $lang:po/$lang.po
 [type: LaTeX] cv_francois_en.tex $lang:cv_francois_$lang.tex

et j’utilise ce makefile

POA=po4a
POACONF=po4a.cfg

SRC=$(wildcard *.tex)
PDF=$(SRC:.tex=.pdf)
LATEX=pdflatex
BIBTEX=bibtex


all: $(PDF)

%.pdf: %.tex
        $(LATEX) $<
        $(BIBTEX) article
        $(BIBTEX) proceeding
        $(LATEX) $<
        $(LATEX) $<

i18n:
        $(POA)  $(POACONF)

clean:
        rm -f *.log *.aux *.toc *.lot *.lof *.nav *.out *.snm *.bbl *.blg

mrproper:clean
        rm -f $(PDF)

Pour compiler, je fais

make i18n
# traduction dans fr.po
make i18n
make

A noter que si vous avez des environnements spécifiques, on peut ajouter des directives dans le fichier tex (la doc détaille ça très bien et en français).

% po4a: environment chapeau

Avec ça, je mets à jour mon CV de manière efficace, en un minimum de temps et d’effort. Si vous rencontrez des besoins de traduction, je ne peux que vous conseiller po4a pour les satisfaire, c’est robuste et flexible.

Mat : supprimer les métadonnées de fichiers

mat est un logiciel libre (GPLv2) utilisable en console et en interface graphique. Il permet de supprimer les métadonnées présents dans des fichiers (images, documents, multimédia). Ces métadonnées peuvent contenir des noms d’auteur, des numéros de série d’appareil ou encore des données de localisation.

Je suis le mainteneur du logiciel pour archlinux. Mat est écrit en python, il utilise la bibliothèque hachoir permettant le lire les informations dans des fichiers binaires (le nombre de format pris en compte est impressionnant).

Dans le cadre de publications de ces documents (comme une galerie photo statique), on peut vouloir éviter de donner ce genre d’information (et en plus, ça fera toujours des photos plus légères !)

Pour voir l’effet sur des photos, vous pouvez utiliser l’outil exiftool. (licence GPL, il fonctionne d’ailleurs sur de nombreux formats dont pdf).

Bon nettoyage !

wiki versionné avec git

Dans la vie numérique, j’aime git et j’aime les wiki que ce soit pour un usage collaboratif ou personnel.

Celles et ceux d’entre vous qui me suivent savent que j’utilise zim afin de conserver mes notes privées ou n’ayant aucun intérêt à être divulguées. Zim se définit comme un wiki de bureau.

Il se trouve que je viens d’avoir un nouveau besoin : répertorier des petits bouts de code présentant des syntaxes ou des usages de bibliothèques que j’ai cherché au moins une fois. Zim ne propose pas de coloration syntaxique pour ça et la demande de colorisation de texte est un bug ouvert (d’après mon souvenir).

Bref, toujours curieux, toujours prêt à tester de nouvelles solutions, je me suis mis à chercher des wikis en ligne avec git comme gestionnaire de version. En effet, je veux retrouver les avantages que j’ai avec Zim à savoir :

•   reposer sur des fichiers textes avec de préférence une syntaxe non ésotérique

•   être accessible hors ligne, ce qui signifie avoir une copie locale complète

Ce dernier point étant important, car si mon serveur tombe ou si je n’ai plus de moyen de me connecter, je veux toujours accéder à mes données.

J’ai trouvé et testé deux solutions. Il en existe peut être d’autres qui m’ont échappé. La première se nomme gitit. C’est codé en haskell, ca ressemble beaucoup à mediawiki. L’installation sur un serveur debian s’est passée sans encombre à l’aide du paquet fourni et de la doc. J’ai été vraiment séduit à l’usage notamment par le support de différents langages de balisage léger, l’export dans N formats (epub, pdf, tex et j’en passe), c’est pandoc qui est derrière, donc du costaud. A noté aussi le support mathml et la possibilité de faire des slides en html5 (j’ai trouvé ça génial).
J’ai été déçu quand je me suis rendu compte que le support coloration syntaxique demandait de recompiler le logiciel (sauf si j’ai raté quelque chose, le paquet debian ne semble pas avoir ce support). ce n’est pas insurmontable, mais sur le coup, je n’ai pas eu envie.

Retour moteur de recherche et je suis tombé sur ikiwiki. Après un coup de ménage sur le serveur, j’installe donc ce palindrome. Là aussi, paquet + doc rendent ça très facile. Au passage, heureusement que les lib perl sont empaquetées, il y en a une belle quantité.
Je n’ai pas pris l’installation manuelle, la version "automatique" + ajustement ultérieur m’a semblé suffisant. L’interface par défaut est moins sexy que gitit, mais on peut trouver quelques css. Il existe aussi une foule de greffons dont un qui gère des refs via bibtex. Pas encore testé, mais ça m’intéresse grandement. Coté fonctionnalité, j’ai presque l’impression que c’est le négatif que gitit. J’aimerai voir tous les avantages que j’ai cité dans gitit chez ikiwiki. Notamment, pas de mathml mais un greffon qui fait du dvipng
Ikiwiki fait un build des pages grâce à un hook git, donc dès que vous poussez votre version, ça reconstruit un html statique à partir du (des) fichier(s) modifié(s) servi par votre serveur web. Etant donné les langages et le plus grand nombre de greffons, ikiwiki remporte mon intérêt. En effet, je peux coder un peu en perl et j’ai vu qu’il est possible de coder des greffons en python.

Une remarque importante est que ikiwiki peut être utilisé comme un blog statique. J’ai remarqué qu’un certain nombre d’auteurs retournait sur ce genre de solution après une expérience de CMS comme wordpress. Il est vrai que la légèreté (important pour les lecteurs aux faibles débits et les auto-hébergés) et l’atout rédactionnel déporté sont intéressants. L’intérêt que je verrai à ikiwiki pour cet usage serait les commentaires gérés sans service externe (cf ce blog à titre d’exemple).

Même si je n’ai pas encore rendu Zim, je me rend compte que ikiwiki serait plus adapté à mes usages. Zim m’aide beaucoup en tant que wiki, mais peu en terme d’utilisation et de fonctionnalité. Je n’aime pas l’éditeur d’équation, l’import d’image ou l’absence de support syntaxique.

Si certain(e)s ont un expérience dans ce domaine, je suis preneur ; autrement je vous laisse décrouvrir

Détection de cercles par une transformation de Hough dans scikit-image

Au détour de quelques questions que je me posais que la détection de forme, j’ai découvert les transformations de Hough. Ces transformations permettent, en jouant avec la géométrie de détecter par exemple des droites ou des cercles dans des images. Le principe est basé sur un accumulateur construit dans un espace réciproque à l’image dont les maxima marquent les formes probablement existantes dans l’image binarisée.

En quelques mots, pour des droites, l’idée est de balayer toutes les pentes et toutes ordonnées à l’origine et de compter le nombre de pixels matchant la droite de test avec l’image.

Scikit-image est une bibliothèque sous licence libre pour Python spécialisée dans la traitement d’image trouvant son socle technologique dans numpy et scipy. La transformation de Hough pour les lignes existait déjà, mais pas pour les cercles.

J’ai donc implémenté cette détection dont l’image ci-dessous illustre le résultat sur une photographie d’une série de pièces de monnaie. Dans l’exemple, on fait une tentative en précisant 2 rayons et en récupérant deux possibilités par rayon. Un des intérêts que je vois dans cette méthode est l’estimation de la position du centre de cercle qui peuvent être importants pour d’autres traitements postérieurs.

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.patches as mpatches

from skimage import data, filter
from skimage.transform import hough_circle
from skimage.feature import peak_local_max

# Load picture and detect edges
image = data.coins()[0:95, 70:370]
edges = filter.canny(filter.sobel(image), sigma=2.8)


fig, ax = plt.subplots(ncols=1, nrows=1, figsize=(6, 6))
ax.imshow(image, cmap=plt.cm.gray)

# Detect two radii
radii = np.array([21, 25])
hough_res = hough_circle(edges, radii)

for radius, h in zip(radii, hough_res):
    # For each radius, keep two circles
    maxima = peak_local_max(h, num_peaks=2)
    for maximum in maxima:
        center_x, center_y = maximum - radii.max()
        circ = mpatches.Circle((center_y, center_x), radius,
                               fill=False, edgecolor='red', linewidth=2)
        ax.add_patch(circ)

plt.show()

Petite remarque. J’ai appris aussi à cet occasion l’algorithme permettant de dessiner des cercles ou des lignes (Bresenham) et que celui-ci présentait le défaut ne pouvoir faire des cercles concentriques formant un disque plein. L’algorithme d’Andres est alors la solution pour ça (il supporte mieux la rotation aussi). Le premier était implémenté dans Scikit, pas le second, ce que j’ai corrigé. A noté que j’utilise Bresenham pour Hough car il me semble plus approprié (moins de redondances locales)

Prolégomènes à l’installation de mon serveur

Dans ce billet, je vais décrire les quelques étapes préliminaires que j’effectue avant d’installer des services sur un serveur que j’administre.

Sauvegarde

Je commence par mettre en place mon script de sauvegarde. Comme je suis en auto-hébergement, j’ai une autre machine sur mon réseau local qui fait office de disque externe. Je rapatrie aussi des sauvegardes sur une autre de mes machines portables qui est à l’extérieur. En gros, je sauvegarde

1. /var/www
2. /etc
3. /home

Sauvegarder /etc peut peut-être vous surprendre. Disons que mes notes peuvent être lacunaires et si j’ai besoin de remonter une machine rapidement, ce sera toujours moins stressant/plus facile d’avoir cette feuille de triche sous la main.
Comme dans la suite je vais mettre en place un certain nombre de service, ça me donnera l’occasion de vérifier que ça tourne bien.

A noter que mon /etc est suivi avec etckeeper. C’est pas de la sauvegarde, mais je vais le ranger ici.

Monitoring

J’aime que ma machine me parle. J’utilise deux projets. Logwatch et monit.Logwatch surveille les logs et m’envoie chaque matin une version "digérée". Ca me permet de savoir que ma machine est bien vivante à chaque petit dej.
Monit permet d’envoyer des alertes quand un événement se produit : redémarrage/arrêt d’un service, utilisation élevée du CPU…

Ceci dit, je n’aime pas trop la configuration de monit. Peut-être que supervisord pourrait me donner plus grande satisfaction. (Des avis ?)

Il existe bien sûr des solutions plus évoluées, mais elles le sont beaucoup trop quand on est en possession d’une petite machine et non d’un parc de machines.

Investigation

Ca, c’est pour le moment où je suis arrivé sur la machine. J’aime avoir :

1. htop (top en mieux)
2. iotop (le top les IO)
3. glances Super outil.
4. des outils réseaux (host, dig, nslookup, traceroute…)

Pour glances, je ne le range pas dans le monitoring car même s’il a une gestion client/serveur, je considère que le monitoring ne doit pas me demander de rester rivé sur un écran.

Santé

Coté santé de la machine, je mets

1. smartmontools. Ca donne la possibilité d’être prévenu d’un futur pépin.
2. lm-sensors pour les températures.

Prévention

En vrac :

1. ntp (On s’assure que les logs sont à l’heure, si on doit recouper l’information, ce sera utile ; et puis avoir une machine à l’heure, c’est bien)
2. par-feu : ufw simple et efficace
3. safe-rm : afin d’éviter les catastrophes, on blacklist des répertoires sensibles
4. molly-guard pour éviter un arrêt malheureux à distance.
5. fail2ban, bien connu je pense…
6. rkhunter

Mise à jour

Là, c’est spécifique à l’OS. Pour debian :

1. apt-listbug : vérifie les rapports avant d’installer un paquet
2. cron-apt  : vérifie la disponibilité de maj et envoie un courriel

Fin

Je pense avoir fait le tour. A titre indicatif, smartmontools et monit m’ont donné des alertes pertinentes. SI vous avez des alternatives ou des compléments à suggérer, je suis ouvert

Test continu de la compilation d’un document *tex avec python

Rédigeant mon manuscrit, je ne me voyais compiler toutes les cinq minutes mon documents pour voir si je n’ai pas fait une erreur. En effet, détecter une erreur rapidement permet de la corriger facilement surtout que les compilateurs latex et consorts donnent parfois des erreurs peu facile à décrypter.

L’idée est donc de compiler le document automatiquement à chaque dois que je l’enregistre. Une bulle (lib notify) est affichée de manière à prévenir du succès ou de l’échec. Faire ça en python, c’est très simple avec watchdog et pynotify. Quelqu’un avant moi a déjà pensé à faire quelque chose comme ça.

Dans mon cas, je n’utilise pas de makefile. Je fais donc mon appel xelatex directement. J’utilise subprocess.check_call() afin d’avoir le code de retour de xelatex.

Avec pynotify, j’ai une exception gobject.GError qui est parfois levée. Je n’ai pas d’idée de la raison. Si quelqu’un a une idée… sinon, je chercherai plus tard (ça reste Quick & Dirty).

import subprocess
import os
import time

import pynotify
from gobject import GError

from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler


class ChangeHandler(FileSystemEventHandler):
    """React to modified .tex files."""
    def on_any_event(self, event):
        """If a file or folder is changed."""
        if event.is_directory:
            return
        if os.path.splitext(event.src_path)[-1].lower() == ".tex":
            pynotify.init("Mon appli python")
            try:
                subprocess.check_call(['xelatex', '-halt-on-error' ,'thesis.tex'])
            except subprocess.CalledProcessError:
                message = pynotify.Notification("Build failed.")
            else:
                message = pynotify.Notification("Build done.")
            try:
                message.show()
            except GError:
                pynotify.uninit()  # methode brute !
                print('Gerror')
                pynotify.init("Mon appli python")



def main():
    handler = ChangeHandler()
    observer = Observer()
    observer.schedule(handler, '.')
    observer.start()
    try:
        while True:
            time.sleep(1)
    except KeyboardInterrupt:
        observer.stop()
    observer.join()


if __name__ == '__main__':
    main()

Autohébergement : un an et demi plus tard

J’écrivais il y a un an et demi mes premiers pas vers l’auto-hébergement, il est temps d’écrire un petit bilan. En effet, je viens de faire table rase sur ma machine pour repartir à neuf. Ma nouvelle machine répondant au doux nom de clématite.

Les raisons d’hier sont-elles celles d’aujourd’hui ?

Reprenons les point par point.

• Apprendre (parce que mine de rien, ce n’est pas trivial)

C’était l’un de mes objectifs; et ça l’est toujours. J’ai beaucoup progressé en un an et demi, sans forcément y consacrer beaucoup de temps. Je maitrise mieux les briques email et DNS. J’ai appris tout un tas de choses (détaillées plus bas). Pour moi, c’est un point fort qui continue à l’être car j’ai encore beaucoup à apprendre.

• Synchroniser des fichiers en maîtrisant mes données

Objectif validé. J’utilise git avec en plus une interface web "de secours" dans le cas où je veux accéder à ces fichiers depuis une machine ne disposant pas de git. Ceci me permet d’avoir une copie de mes documents les plus précieux dans des endroits éloignés. Usage quotidien.

• Avoir la possibilité de monter quelques pages web

Objectif validé aussi. Ma page perso-pro, initialement hébergée sur le serveur de mon laboratoire, est passée sur mon serveur. J’utilise pour cela un CMS sans base de donné tout à faire suffisant pour cela (Get Simple).

• Echanger quelques fichiers via ftp

Abandonné. Ma config marchait très bien et finalement, j’envoie sur le serveur web de mon labo. C’est une solution quick and dirty. Je dois chercher ce qui peut me convenir.

• Récupérer mes flux RSS. Thunderbird montre ses limites quand il s’agit d’être déconnecté un bout de temps.

Objectif validé. J’utilise rss2mail. Buggué, mais il fonctionne parfois par magie. J’ai entrepris un fork répondant mieux à mes besoins. Ce système est clairement un point fort pour moi.

• Et pour toutes les fois où il est utile d’avoir une machine distante

J’établis un proxy SOCKS dès que j’utilise un wifi. J’ai par ailleurs mis en place un "proxy web" me permettant d’avoir un navigateur dans un site web en quelque sorte. Non public pour des raisons évidentes de sécurité.

• Ainsi que ce que je n’ai pas encore pensé

Pas beaucoup plus. J’ai essayé owncloud que j’ai abandonné. Trop immature et pas indispensable. J’ai mis en place linkchecker en cours de route pour vérifier les liens morts. Actuellement, je déploie une solution de stats (très simple) pour avoir des idées sur le nombre de visite.

Pourquoi ce nouveau départ ?

Simplement pour des raisons techniques. A l’époque, j’avais choisi gitosis pour propulser mes dépôts git alors qu’il n’est plus maintenu. J’ai préféré passer à gitolite. Le point noir fût le choix du serveur web. Lighttpd m’a donné la migraine lors de sa configuration. Forcer le passage en https sur un sous-domaine avec un mod authentification… et bien je n’ai jamais réussi ça proprement. J’étais motivé par ce serveur pour la réputation de légèreté. Vu le faible trafic, cet argument n’était pas pertinent. Je suis passé à apache. Documentation abondante, la configuration donne une impression de rigueur. J’ai enfin pu faire ce que je voulais. Pour terminer, j’utilisais ssmtp et je suis passé à postfix : il y a des logs et c’est tout de même un plus.

Tout ça ne méritait pas forcément un réinstallation, mais c’était l’occasion ! J’ai ainsi pu mettre à jour mes notes concernant mon installation.

Les problèmes rencontrés… en vrac

J’ai eu quelques difficultés avec iptable. J’utilise désormais ufw. Simple et efficace. J’ai subit une ou deux coupures de courant pallié maintenant par un UPS (Eaton 650) qui tient une demi-heure avec le modem-routeur. Justement, ce modem-routeur m’a causé quelques soucis puisqu’il a rendu l’âme il y a quelques mois. Le temps de recevoir le nouveau et que je me déplace (oui auto-hébergement pas chez moi ), j’ai du basculer sur des solutions de sauvetage. C’est là que j’ai réalisé que mes backups complètes étaient aussi à distance. Ce point est amélioré avec des backups à divers positions géographiques que je fréquente. Néanmoins, mettre en place une solution de substitution intégrale reste difficile à causes de contraintes pratiques. Un point à approfondir donc.

Futur

Je vais étudier la mise en place de ce blog sur mon serveur, c’est à dire un déploiement wordpress + mysql et maintenance. C’est en cours d’essai sur une machine de test. Cette machine de test est d’ailleurs un avantage : j’ai pu migrer mon serveur sans interrompre mon site web et le faire rapidement.

Utiliser la machine de test pour essayer les mises à jour de CMS.

Comme dis plus haut, quelque chose pour échanger des "pièces jointes" trop volumineuses. Je dois réfléchir sur mes besoins précis.

Travailler sur l’anticipation et la réaction à une panne internet ou serveur.

Mes dépôts git public sont sur github. Puisque github a décidé de supprimer la fonctionnalité download. les tarballs sont sur mon serveur mais je continue à utiliser github pour les dépôts. Je n’y vois guère de danger car ces dépôts sont aussi sur mon disque. Ceci dit, si github ne me plaît plus, je réfléchirai à gitlab ou redmine.

Je me dois aussi de réfléchir à des notebooks ipython. La performance et la consommation de ressources que cela peut générer me freine un peu.

Un besoin n’est pas totalement satisfait pour linkchecker. Je souhaite qu’il me notifie par email des nouveaux problèmes sur un site. Le projet linkchecker est malheureusement trop bas niveau puisqu’il se contente de générer un rapport. Si un lecteur connaît une solution existante, je serais heureux de l’écouter

Je ne prévois pas d’héberger moi même mes courriels. C’est relativement critique et j’ai un registar qui m’offre un espace suffisant. J’évite ainsi les gros en me permettant de basculer sur ma propre solution le jour venu sans changer d’adresses.

Conclusion

Je ne suis pas prêt d’arrêter. Maîtriser ses données et faire de l’internet sont de belles motivations. Je considère que ces connaissances deviennent très  fondamentale et que les avoir est un atout indéniable.

Merci à VX et Echarp pour les discussions.