Après 7 mois de développement, la version 0.1 de Dynastie est en ligne. Dynastie est un générateur de blog statique, c'est-à-dire qu'il va générer un ensemble de pages HTML statiques à partir de modèles (template) et d'articles. Contrairement à l'ensemble des moteurs de site web dynamiques où les pages sont regénérées à chaque connexion. L'avantage d'un tel procédé est qu'on ne fait le travail qu'une seule fois. Il suffit ensuite de servir les pages qui existent déjà avec nginx (qui est très bon pour ça). On optimise ainsi le temps de réponse et la charge serveur (qui n'est pas très puissant).

C'est tellement simple à réaliser qu'il y a une multitude de générateur disponibles sur le net. J'aurais pu utiliser un de ceux là, mais il manquait plusieurs fonctionnalités :

• Un éditeur WYSIWYG accessible via une interface web
• Écrit en Python
• La compression gzip des pages générées
• Qui accepte le HTML en entrée
• Qui n'utilise pas Disqus
• Qui n'utilise pas Mako/Jinja/Cheetah (des moteurs Python)
• Qui est simple

Au début, j'ai commencé par un site en PHP, mais j'ai rapidement abandonné au profit de Python et surtout du framework Django. J'ai tout de suite été conquis par sa simplicité. Bref, Dynastie supporte toutes les fonctions traditionnelles d'un blog et même plus :

• Index dans l'ordre anti chronologique
• Categories
• Tags
• Flux RSS/Atom
• Commentaires (dynamiques et sans Disqus)
• Recherche (dynamique)
• éditeur WYSIWYG en ligne
• Coloration syntaxique (avec Pygments)
• Prévisualisation
• Multi blogs
• Multi utilisateurs
• On ne regénère que ce qui est nécessaire

Les principes de Dynastie sont simples :

• Les articles sont stockés dans des fichiers HTML séparés
• Les méta informations (titres, tags, commentaires, ...) sont stockées dans une base de données SQLite ce qui permet une manipulation aisée
• Les modèles sont stockés sous le dossier "sites/<nom du site>", ils sont constitués de pages HTML avec des directives en XML (contrairement à la plupart des générateurs) pour interagir avec le moteur

Lors de la génération, Dynastie mélange tous ces éléments dans le dossier "sites/<nom du site>_output". Il copie aussi tous les fichiers ne commençant pas par "_" (qui sont les fichiers de modèle en général). Mais ça ne s'arrête pas là : il est possible d'ajouter "à la volée" des commentaires ainsi que de faire des recherches dans les pages du site généré. C'est cet aspect à la fois DYNAmique et StaTIquE qui a donné son nom au générateur.

Tous ces éléments d'architecture justifient sa création, qui est plus qu'une simple copie. Bien sûr, le design général du site fait pitié, mais c'est simple et efficace !

Aujourd'hui nous allons répondre à une problématique concernant la sécurité et le travail en équipe. Lorsque le travail requiert des besoins importants en terme sécurité, il arrive de devoir mettre en place des dossiers chiffrés pour protéger des documents confidentiels. Pour cela, la solution idéale est TrueCrypt : le volume sécurisé est monté et seul l'utilisateur peut y accéder (pas de montage réseau possible). Mais quand on travaille à plusieurs sur les mêmes documents, il faut créer un TrueCrypt par machine et synchroniser les fichiers "à la main"...

Bref, ce temps est révolu. En combinant SSHFS et EncFS on peut créer des dossiers chiffrés et y accéder à distance de façon sécurisée (à tous les niveaux). Il faut mettre en place un "serveur" qui va centraliser les dossiers et une installation sur chaque client comme suit

Sur le serveur

Installer encfs

sudo apt-get install enfs

Éditer le fichier /etc/fuse.conf pour autoriser les utilisateur non root à utiliser fuse
Décommenter "user_allow_other"

La commande "ls -l /dev/fuse" devrait donner le résultat suivant

crw-rw---- 1 root fuse 10, 229 Jan 24 12:05 /dev/fuse

Si le groupe "fuse" n'a toujours pas accès à /dev/fuse, il faut redémarrer la machine (c'est le cas notamment sous Debian).

Créer un utilisateur spécifique pour le projet

sudo adduser PROJET

Ajouter l'utilisateur au groupe fuse

sudo adduser PROJET fuse

Démarrer un shell avec l'utilisateur PROJET

su PROJET
cd

Créer le dossier qui sera chiffré

mkdir projet_enc

Faire le montage du dossier encfs dans le dossier "projet_enc_out"

encfs /home/PROJET/projet_enc /home/PROJET/projet_enc_out

Quitter

exit

Sur chaque client

Installer sshfs

sudo apt-get install sshfs

Éditer le fichier /etc/fuse.conf pour autoriser les utilisateur non root à utiliser fuse
Décommenter "user_allow_other"

La commande "ls -l /dev/fuse" devrait donner le résultat suivant

crw-rw---- 1 root fuse 10, 229 Jan 24 12:05 /dev/fuse

Si le groupe "fuse" n'a toujours pas accès à /dev/fuse, il faut redémarrer la machine (c'est le cas notamment sous Debian).

Ajouter courant l'utilisateur au groupe fuse

sudo adduser USER fuse

Créer le point de montage

mkdir projet_secret

Monter le dossier chiffré distant

sshfs -o uid=$UID gid=$GID PROJET@IP:/home/PROJET/projet_enc_out projet_secret

Démonter le dossier

Que ce soit sur le serveur ou sur le client, il n'y a qu'une seule commande

fusermount -u <point_de_montage>

Conclusion

À l'intérieur de ce dossier on peut ensuite créer un dépôt git et faire un clone : ça donne un git distant sécurisé (même si on a l'impression d'y accéder en local). On peut aussi inscrire les clés publiques pour l'utilisateur PROJET et donc restreindre l'accès à certaines machines uniquement, ce qui a pour effet de bord d'avoir un mot de passe différent pour chaque utilisateur et non un mot de passe commun !

Mon Sheeva est tombé un lundi matin (le 7 janvier). J'ai reçu l'alimentation deux semaines plus tard... Le serveur a pu redémarrer vers 16h, mais les plus attentifs auront remarqué que le blog était en ligne depuis le mardi 8 janvier 11h. C'est le résultat de mes premiers pas dans les nuages. La situation est critique : l'alimentation a lâchée, pas de serveur de secours sous la main (mais les sauvegardes sont là), pas de serveur distant, impossible de laisser tourner un PC h24 et (a priori) quelques jours à attendre avant d'avoir la pièce de rechange.

Le blog est la partie la plus visitée, il fallait au moins essayer de le remettre en ligne. Pour le coup, le passage à un blog statique simplifie énormément les choses ! Bref il faut trouver un petit espace de stockage en ligne pour pas longtemps et pas trop cher (tant pis pour les autres services, ils ne sont pas critiques et je ne voulais pas perdre du temps à configurer une instance qui sera détruite par la suite).

Je suis référencé chez Gandi, j'ai donc cherché par là. Concernant les sites web simples, ils ne proposent que la création via Gandi BaseKit ou Sitemaker à partir de 5€ par mois. Sinon, ils ont une solution "Simple Hosting" : un pack PHP/MySQL ou PHP/PostGre à partir de 5€/mois, ça pourrait presque être adapté, mais je ne voulais pas souscrire pour un mois. Enfin, dernière option : les nuages (le cloud) : louer une part d'un serveur que l'on peut relâcher quand on n'en a plus besoin. Bingo ! Je paye via mon compte pré payé (le surplus servira pour le renouvellement du nom de domaine). Une fois l'instance crée avec une Debian stable 64 bits (quelques minutes), un petit SSH, on installe emacs, nginx, un autre coup de scp, on reconfigure la zone DNS et roulez jeunesse, le blog est de nouveau en ligne. Les mails sont redirigés sur le webmail de Gandi. C'est une solution de secours flexible, pas chère (0.50 euros par jour) et très intéressante (surtout quand on a déjà tous les fichiers de conf) puisqu'on maîtrise tout (ce qui est plus facile pour adapter son ancienne configuration) avec en prime une addresse IPV6. Pour ce prix-là, j'ai :

• 1 coeur dédié
• 512Mo de mémoire
• 12 Go de disque
• Une connexion 10Mbits

De loin on pourrait dire que c'est à peu près la même chose que le Sheeva (hors débit de la connexion), sauf qu'en fait ça va VRAIMENT plus vite. Suite à l'aller-retour de l'alimentation en Angleterre (...), j'ai quand même ré installé la majorité des services sur l'instance.

En réalité, ça fait quelques semaines que j'y pensais. Lorsque ce sera possible, il faudrait installer un serveur de secours (fallback) pour faire face à un problème matériel, un crash de disque ou même une connexion qui tombe. C'est un gros problème de l'auto hébergement : pas de réplication des ressources. Tandis que dans les gros datacenter de Gandi, tout est virtuel, dupliqué 15 fois sur plusieurs sites physiques et avec des débits plus qu'intéressants. Bref, avoir deux serveurs physiques c'est presque jouable (ami, famille ...). Les problèmes sont les suivants :

• Le DNS : si l'IP change tout le temps des deux côtés, c'est galère. On doit s'appuyer sur un serveur DNS fixe et éditer les zones en évitant les conflits (ou activer/désactiver manuellement l'édition des zones sur le serveur qui va bien). Il faut au moins avoir une IP fixe sur les deux (pour avoir un DNS primaire/secondaire).
• Les données utilisateurs : un simple rsync suffit
• Les projets versionnés : a priori une simple copie des fichiers suffit, mais c'est plus élégant de faire un clone/checkout des dépôts
• Base de données : la plupart des moteurs incluent un système de maître/esclave

Il existe quelques solutions qui prennent en compte tous ces paramètres ou faire un script perso, reste plus qu'à le mettre en place si j'achète un nouveau serveur !

Concernant ma solution dans les nuages, je pourrais aussi faire un script de migration (copie, installation et configuration des paquets sur un nouveau serveur virtuel).

Et pour le plaisir :

Le SheevaPlug est mort, vive le SheevaPlug !

Suite à mon dernier article concernant le travail le dimanche, mon SheevaPlug a décidé de se mettre en grève ! À mon réveil lundi matin (7 janvier) : plus rien ! Ma première idée est qu'il y a eu une coupure de courant et qu'il a eu du mal à redémarrer sur la clé USB, Ubuntu ayant pour sa part planté. Pourtant, je n'arrive pas à me connecter par le lien série. Les symptômes sont :

• Une seule des deux LED du frontpanel est allumée
• Les deux LED de l'ethernet sont allumées

Et pourtant, rien ne marche :( En consultant le net, je retombe régulièrement sur LE problème du SheevaPlug : son alimentation. Ce serait donc la PSU (Power Supply Unit) qui aurait lâché. Quatre coups de tournevis plus tard (et surtout en suivant ces instructions), je découvre ça :


Je ne comprends pas grand-chose en électronique, mais je me dis que ça a vraiment été monté à l'arrache. Elle aura quand même tenu 2 ans et demi (donc la garantie de 12 mois a expirée depuis bien longtemps), ce qui est quand même très bien (ça fait du 3.61€ par mois). J'ai ensuite commandé une nouvelle alimentation sur newit (ils ont tout prévu !) : 26.5€ avec les frais de port. J'aurais pu en acheter une chez un marchand d'élec, mais je ne voulais pas qu'elle pende lamentablement à l'extérieur, ni avoir à souder. J'espère que celle-ci tiendra au moins aussi longtemps que la précédente.

PS : Lors du voyage par Royal Air Mail, ils ont oublié de préciser les informations additionnelles, du coup elle a fait un joli aller-retour et j'ai pris deux semaines dans les dents + le prix d'un transporteur TNT. Du coup le transport a coûté plus cher que l'alimentation en elle-même.

Une fois la nouvelle alimentation installée : Oh miracle ! Ça fonctionne !!!! J'ai même pu tuner mon Sheeva avec un embout blanc sur un fond noir.

CuBox

Régulièrement je regarde le site newit pour voir les nouveautés. GlobalScale Technologies (le constructeur du SheevaPlug) s'est rapidement éloigné de la philosophie du Sheeva (le GuruPlug a eu un succès mitigé) : on rajoute un disque dur, on rajoute le wifi, on rajoute le bluetooth, on rajoute le HDMI... Mais on garde le même processeur et la même quantité de mémoire... Alors qu'il fallait faire tout l'inverse : garder un appareil petit avec quelques connexions (le double ethernet peut être sympa) tout en augmentant la puissance (processeur et mémoire). Solid Run (une startup de seulement 7 personnes !) l'a bien compris en sortant la CuBox. Pour moi c'est le digne successeur du SheevaPlug :

• Marvel PJ4 (Dual Cortex A8) @ 800Mhz
• 1GB de DDR3 32 bits @ 800Mhz
• GPU OpenGL ES / Décodeur HD / HDMI (c'était dans le SoC)
• InfraRouge
• 1 Gigabit Ethernet / 2 USB / 1 eSata / 1 SPDIF / 1 MicroSD
• 55mm x 55mm x 42mm

Plus petit (le Sheevaplug fait 110 mm x 69.5 mm x 48.5 mm), plus puissant et le tout pour 3 Watts (comme le Sheeva). Le prix est identique à celui du Sheeva (130 €). Et pour ceux qui sont un minimum patient, une version à 2GB (CuBox pro) devrait sortir fin janvier. Si elle avait été disponible de suite (ou pré commandable depuis le site de Solid Run, qui ne livre pas en France...), je l'aurais bien échangé contre mon Sheeva qui commence un peu à ramer quand on lui demande du PHP ou du Python ! Au passage, j'ai remplacé ma clé USB Toshiba par une SDCard 16GB class 10 : en plus d'accélérer les entrées/sorties elle devrait être plus fiable.

La CuBox sera incontestablement ma prochaine acquisition pour un serveur perso (à faible charge, s'entend). D'ici là, c'est bien de voir comment va se comporter le hard, qui vient tout juste de paraître (on n'est pas sans rappeler les défauts d'alimentation du Sheeva...).

Nouveau service sur Cybelle : un serveur XMPP ! J'avais longtemps hésité à en installer un, vu le peu de ressources disponible sur le serveur, peur aussi de l'erlang, mais finalement j'ai été séduit par Prosody ! C'est un serveur très léger écrit en Lua.

J'ai même pu écrire un premier patch (en Lua !) qui sera peut-être intégré dans la future stable (0.9). Bon, pour l'instant je suis un peu seul, mais c'est quand même classe d'avoir une adresse de messagerie instantanée à son propre nom !