Ce billet est en réponse à celui publié par Genma. Je possède un point de vue différent de l'autohébergement et je pense que ça peut contribuer à la réflexion.

En bref, ce que nous dis Genma :

• On veut s'échapper des GAFAM à l'heure de la surveillance de masse.
• S'auto-héberger demande des compétences techniques.
• On pourrait donc mutualiser à une échelle locale l'hébergement par une structure associative.

Dans cette réflexion, il manque selon moi un point important qui porte sur la hiérarchisation. Nous parlons de vie privée. Envers qui je souhaite la protéger ? On peut répondre par cercle (degré du lien, temps partagé...) : la famille, les amis, les voisins, les entreprises (de son pays ou non), la presse, son Etat, les autres Etats.

Si on prend part à la réflexion de Genma, on ne regarde que les cercles étatiques et éventuellement des entreprises. La question est maintenant la suivante : qui est le plus à même d'avoir un intérêt pour mes informations ? Si on est Snowden, alors Genma a raison, il faut se méfier beaucoup des Etats, mais à l'évaluation du risque, on ne se risquera pas à mettre sa vie entre les mains d'une association. Maintenant, si je suis une personne lambda, c'est-à-dire que je n'ai pas de notoriété publique, les personnes pouvant être intéressés par ma correspondance sont les personnes de mes cercles proches (donc familles, amis, voisins). Qui me dit qu'un voisin ne trouvera pas un comportement banal un peu louche ? et décidera d'approfondir, parce que vous comprenez... En terme de probabilité, c'est bien plus important que l'état quand on "n'a rien à se reprocher mais quand même quelque chose à cacher" (cf conférence de J. Vaubourg par ex.).

Le terme autohébergement désigne l'hébergement d'un serveur chez soi. Il ne dit pas ce qu'il y a sur ce serveur. Toujours en cercle, cette fois-ci de vie privée :

• synchronisation de données (photos, vidéos, documents administratifs)
• correspondance (courriel, vidéo-conférence...)
• hébergement de fichiers (pour partage privé)
• hébergement de sites semi-publiques
• hébergement de sites publiques

Le haut de la liste est peu appropriée à l'hébergement associatif, le bas de la liste l'est d'avantage, la frontière est à délimiter par chacun. En d'autres termes, les GAFAM ne nous protègent pas des structures puissantes (états, entreprises) mais nous protège pas trop mal des structures proches (voisins...). Je dis "pas trop" car il peut y avoir des failles et/ou des divulgations publiques. L'hébergement associatif est juste le contraire de cette situation (protection contre les structures puissantes par délocalisation mais vulnérabilité aux proches). Le véritable auto-hébergement tend à peser sur toutes les sphères, sans pour autant que ce soit parfait car sécuriser un serveur n'est pas facile et dans certains cas, on peut vouloir s'en remettre à une association ou une petite entreprise.

En résumé, je pense qu'il faut se méfier des règles génériques et chaque élément doit être analysé séparément afin d'accorder la difficulté technique de chaque solution possible avec le produit des risques de perte de vie privée liés à l'ensemble des acteurs et des conséquences (i.e. risques * conséquences).

L'idée de ce billet est d'avoir un github chez soi. Plusieurs raisons à cela :

• J'ai des dépôts privés. Github propose des dépôts privés payants, mais je n'ai pas confiance dans github pour respecter ma vie privée.
• J'ai des dépôts semi-privés. Idem à ci-dessus, je veux un cercle restreint.
• Je ne sais pas quel est l'avenir de github. Google code a fermé, gitorious de même. Je n'ai pas envie de devoir déménager un jour à la va-vite. Voir Et si github fermait.

L'outil git me permet de versionner :

• mes codes sources (scripts d'adminsys, codes scientifiques).
• mes articles, rédaction de projets, etc.
• mes figures.

Je garde des dépôts séparés pour :

• mes wiki et blog (géré par ikiwiki)
• mes dépôts git-annex (qui me permettent de synchroniser des fichier dont la masse totale fait plusieurs gigaoctets).

Il faut donc une gestion fine des permission, ce que gitweb ne permet pas (à ma connaissance).

Deux possibilités :

• gitlab : version entreprise + version communautaire. Des fonctionnalités ne sont pas disponibles dans la version communautaire comme le support de git-annex.
• Gogs : communautaire, plus jeune et prometteur.

A terme, si Gogs se développe, il sera intéressant. Pour l'instant, je reste sur gitlab qui est une valeur sûre en terme de maturité.

Framasoft ne propose pas (encore) d'explications pour installer gitlab sur sa machine, comme il le fait pour d'autres de ses services sur framacloud. On va donc s'atteler à la tâche (A noter que j'écris la suite de mémoire, je n'ai pas eu de difficultés particulières à la configuration une fois que j'ai su comment j'allais m'y prendre).

On commence à suivre les instructions d'installation sur https://about.gitlab.com/downloads/#debian8. En effet, l'application est empaquetée, ce qui nous facilite grandement la vie.

Ensuite, on va dans /etc/gitlab/gitlab.rb pour faire tourner notre instance sur le port 8888

external_url 'https://git.sciunto.org:8888'
# Unicorn
unicorn['worker_timeout'] = 600
unicorn['port'] = 8888
# Web server
web_server['external_users'] = ['www-data']
# On desactive nginx
nginx['enable'] = false
ci_nginx['enable'] = false

On n'oublie pas l'aspect backup, à agrémenter selon l'infrastructure

# For setting up backups

J'ai une instance apache sur ce serveur, je vais donc faire en sorte que apache serve les pages qui sont sur le port 8888. En clair, on mets en place un reverse proxy. Ma configuration est basée sur cet exemple, on n'oubliera pas de modifier le port 8080 pour le 8888. Une liste de modules est présente dans l'en-tête. Ils doivent être activés avec la commande a2enmod.

On reconfigure et relance tout le monde :

sudo gitlab-ctl reconfigure
sudo service apache reload

Après ça, on a un beau gitlab qui tourne.

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

Ce mois-ci n'est pas vraiment un don, mais une cotisation. Sur la résultat, ça reste assez proche. FFDN qui est une fédération qui regroupe un ensemble d'association afin de développer des FAI locaux qui fournissent des services et des accès internet propres. FDN est l'association historique de ce mouvement créé par Benjamin Bayard. Au coté d'autres associations comme la quadrature, FFDN s'est mobilisée sur les récentes décisions politiques. Pour ces raisons, j'ai décidé d'adhérer à cette association pour soutenir le développement d'idées permettant aux gens d'avoir une indépendance numérique. Par la même occasion, j'ai décidé de prendre un accès VPN chez eux.

Enfin, entre FFDN et Yunohost est né la brique internet, objet d'un prochain billet. Ce fût aussi une motivation.

Ce post s'inscrit dans la série des dons pour vous donner envie de contribuer même très modestement à des logiciels libres. Les petites pierres font les grands édifices.

Mes précédents dons étaient destinés à des projets. J'ai découvert très récemment pdf2htmlEX, un logiciel permettant de convertir un pdf en html avec une fidélité exceptionnelle. Le logiciel est d'ailleurs particulièrement adapté pour les équations.

Je tire du README quelques examples:

• Bible de Genève, 1564 (fonts and typography): HTML / PDF
• Cheat Sheet (math formulas): HTML / PDF
• Scientific Paper (text and figures): HTML / PDF
• Full Circle Magazine (read while downloading): HTML / PDF
• Git Manual (CJK support): HTML / PDF

J'ai eu l'occasion de tester ce logiciel sur quelques uns de mes documents (produit avec LaTeX), et je suis bluffé par le résultat. Etant auto-hébergé, l'affichage progressif de l'html améliorera l'expérience utilisateur. C'est donc 7$ qui vont à l'auteur de ce projet ce mois-ci.

J'ai déjà parlé sur ce blog d'un outil pour générer mes figures sans peine ici et là. Je l'utilise dans le cadre de mon travail de recherche.

En quelques mots, l'idée est d'avoir un outil de construction qui converti des sources vers des fichiers finaux tels que eps, pdf, svg, png, avec un support de traduction. il doit gérer des graphiques, des schémas, des graphiques avec des schémas, des formules chimiques, etc. L'outil que j'avais précédemment codé ne me donnait pas entière satisfaction car il reposait sur waf et il n'était pas toujours facile de faire évoluer les règles de compilation.

Les objectifs :

• automatisation (une commande construit tout)
• reproductibilité (je sais comment chaque figure a été générée)
• versionnage des sources (je sais ce qui a pu changer)
• données stockées à un seul endroit (facile à sauvegarder)

Les choix technologiques et le principes ont été expliqués dans les précédents billets. L'utilisation intensive que j'en ai fait (environ 200 à 300 figures générées jusqu'ici) valident totalement ces choix par l'usage.

Le principe étant très simple, j'ai décidé de recoder l'outil (nommé scifig) en python sans dépendance forte à une librairie existante. J'ai tiré profit de mon expérience avec waf pour soigner l'affichage, les logs et le principe de deux répertoires src/ et build/ ainsi que d'un export vers un répertoire de travail. L'avantage que je tire avec un code qui se suffit à lui-même est que l'écriture de règles doit être évident (ou alors, j'ai mal conçu ma bibliothèque).

Par la suite, il faudra que j'ajoute quelques nouvelles fonctionnalités qui me manquent et que j'avais du mal à inclure dans ma précédente version :

• construction rapide (un seul format) pour les retouches des figures
• règles pour matplotlib
• sorties png avec canal alpha et noir et blanc (utile pour vérifier qu'une figure est lisible sans imprimante couleur)

Plus de détails se trouvent sur mon wiki et dans la documentation.