If I often compile under emacs, I use a lot the terminal. Most of people ignore how it's fast and practical to work, not for every tasks but it's perfect for programing. I already talks about Autojump2, today I will present colout. It's true that the terminal miss some colors. For better displays I personaly use black over white, but when you compile some projects, it's hard to see if errors happens.

I tweak colout (written by nojhan) to fit my needs. It's a simple Python software that will color terminal output if it found specific words. The list of words is fix and embedded into the script (unlike the original one that takes them in parameter). My script is available here.

You only need to add colout file into a bin directory (referenced in your $PATH) and edit your .bashrc with (don't forget to make it executable) :

function make() { /usr/bin/make "$@" 2>&1 | colout ;}

So, when you type "make", it will transparently use colout. The only bad thing is that you loss make's returns value.

Example with :

int main()
{
    int a, b;

    b = a+1;
    c = a;

    return 0;
}

It's better, isn't it ?

Some weeks ago I bought a "Ready for PIC" board from MikroElektronika. These board comes with a PIC18F25K22 flashed with a bootloader that receives a program from UART and load it in memory without flashing. The prototype area is very nice for peoples that do not want to weld, it also contains a FTDI chip and can be powered by USB. Plus MikroElektronika supply a GUI software to interact with the bootloader. These GUI is available for Windows and Linux, that's great ! Contrary to microchip, MikroElektronika wants to sell their expensive C/BASIC/Pascal compiler and provide cool boards at a good price. The only thing I regret is that you cannot reset the PIC with the FTDI, you need to press the reset button before and after code is downloaded (so boring...).

Maybe the GUI is useful for electronics peoples, but I found it (on Linux) heavy and sometimes buggy. Moreover you cannot access to serial output just after code is downloaded. So, I wrote a simple console Python program that will download an HEX file with command line and optionally displays the output of UART. This allows to do quicker and simpler tests. You can find the file here, it's licensed under GPL v3.

Un serveur perso c'est bien, un serveur auto hébergé c'est très bien, mais un serveur auto hébergé qui a planté, c'est nul ! L'inconvénient du plantage système est qu'il ne prévient pas, du coup la durée d'indisponibilité peut être longue si l'on ne s'en rend pas compte.

Pour pallier à ce problème, j'ai fait un petit retour vers OVH. Mon compte n'ayant pas été clôturé après la migration du nom de domaine, j'en ai profité pour acheter un pack SMS. Pour environ 10€ TTC, j'ai 100 SMS que je peux envoyer via le web. Ce petit script bash permet de me notifier lorsque le serveur tombe. Bien sûr, il faut pouvoir l'exécuter sur un PC connecté h24...

L'idée est de faire un HEAD sur la favicon de mon blog (qui n'existe pas et qui n'apparaît pas dans les log). La requête est exécutée toutes les 10 minutes. Au bout de 3 échecs successifs (pour éviter les problèmes de changement d'IP), un SMS est envoyé et le script quitte.

#!/bin/bash

BASE_URL="https://www.ovh.com/cgi-bin/sms/http2sms.cgi"
ACCOUNT="sms-sgXXXXX-1"
LOGIN="BBBBBB"
PASSWORD="YYYYYYYY"
FROM="SOUTADE"
TO="%2B33666ZZZZZZ" #+33666ZZZZZZ
MESSAGE="Cybelle%20is%20down" # Cybelle is down
MAX_TRIES=3

TARGET="http://blog.soutade.fr/favicon.ico"

request="$BASE_URL?account=$ACCOUNT&login=$LOGIN&password=$PASSWORD&from=$FROM&to=$TO&message=$MESSAGE&noStop=1"

#echo $request

tries=$MAX_TRIES
while [ 1 ] ; do
    HEAD $TARGET | grep "404" >/dev/null

    # Found
    if [ $? -eq 0 ] ; then
	# Reset counter
	if [ ! $tries -eq $MAX_TRIES ] ; then
	    tries=$MAX_TRIES
	fi
    else
	# Fail
	tries=`expr $tries - 1`
    fi

    # No more tries, send notification and exit
    if [ $tries -eq 0 ] ; then
	GET "$request"
	break
    fi

    sleep 10m
done

PS : Pour utiliser le script, il faut créer un nouvel utilisateur et ajouter un expéditeur depuis l'interface OVH. Attention, les champs doivent être encodés sous la forme URL (voir la partie "encode" de http://soutade.fr/urlunshortener)

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 !