Lire la Suite »]]> J’avais un peu de mal à choisir un titre pour cet article : je le voulais pas trop long et explicite. Je ne veux pas qu’on pense que je fais l’apologie du privateur au détriment des solutions Libres existantes, loin de moi l’idée. Mon idée est plus : « Putain, ça pootrerait si c’était Libre« .

Les occasions sont rares où les Logiciels Libres sont absents d’un secteurs, ou ne font pas le poids face à un logiciel privateur. Desktop, serveur, embarqué, GNU domine sur le plan technique, grâce aux développeurs de talent disséminés à travers le monde mais unis sous la bannière du Logiciel Libre.

Malheureusement, il y a encore quelques domaines ou le Libre est relativement absent, ou inférieur techniquement, ou embarqué dans du matériel difficile ou impossible à se procurer chez nous. Il se peut même que le Logiciel Libre en question n’est pas si Libre que ça… Bref, il y a des situations où on doit ou préfère encore utiliser des logiciels privateurs. Même Richard Stallman doit parfois faire des concessions dans le domaine du Libre (il conduit une voiture qui est emblématique de l’ultra-capitalisme, mais ce n’est pas le sujet).

Premier cas : les plateformes multimédias en réseau. Je ne cause pas des NAS Libres avec serveur UPnP, je parle des platines de salon. J’en ai testé quelques unes, pour finalement opter pour une HDI Dune HD Max. Le firmware n’est pas libre, mais cette platine lit tout, et accède aux fichiers situés sur pratiquement n’importe quel type de partage : UPnP bien sûr, mais aussi cifs, nfs, ftp, la totale. Elle pêche un peu sur la lecture de certains Blu-ray qui ont tendance à la bloquer, et c’est là qu’on se dit : « Si le firmware de cette platine était Libre, ce serait la platine ultime« .

Deuxième cas : les jeux. Il y a de bons projets, de très bons même, mais étrangement, le commun des mortels n’en entend jamais parler. Demandez autour de vous, qui connaît 0AD à part les geeks ? Ou Flightgear ? Ou même OpenArena ? Voire Battle for Wesnoth ?

Ce qui m’amène à aborder un peu plus en profondeur le cas Minecraft.

Le modèle économique de ce jeu est un véritable scandale : il est vendu 20€, sans boîte, et l’essentiel du manuel est écrit par la communauté des utilisateurs. En plus, sa sortie de bêta est relativement récente, alors payer pour un jeu pas fini, non merci. Et pourtant…

Pourtant, le site officiel parle de 5 millions d’acheteurs. Et le jeu est diablement addictif. Quand on installe le jeu la première fois (ou qu’on y rejoue après une longue pause), sans mods sans rien, on s’émerveille devant tout un tas de petites choses, comme la gestion des intempéries, le cycle jour-nuit, les différents environnements, les cavernes, la peur de se faire débusquer par un zombie, etc. Puis après quelques jours, on se lasse un peu, alors on installe des mods, peu ou pas supportés par Mojang. Et là, c’est le pied : de nombreux mods intéressants sont Libres.

Et c’est là qu’on se dit : « Si Minecraft était Libre, ce serait le meilleur jeu du moment« .

Troisième cas : les navigateurs. Ne venez pas vous la raconter avec Chrome (développé par Google, ça se passe de commentaires), Firefox (développé par Mozilla qui pactise avec l’ennemi), ou les dérivés. Tout ça, c’est bien gentil, mais faut lire entre les lignes, et ça, c’est pas normal. Un logiciel Libre, c’est UNE licence compatible GPL et c’est marre. Si on intègre des bouts de code non Libre, on n’a qu’à le réécrire, c’est aussi simple que ça. Et là je parle que des licences, je ne parle même pas des fonctionnalités. Tout simplement inexistantes pour le premier. Bref.

Il en résulte que parmi les 2.5% d’utilisateurs d’Opera, il y a moi. Et un nombre incalculable de GROS geeks.

Et là on se dit : « Si Opera était Libre, ce serait le navigateur ultime« .

Alors je lance une idée comme ça : que pensez-vous que nous montions tous ensemble une pétition pour la libération du code source de certains produits ou logiciels privateurs que nous, geeks, utilisons ? Si l’idée vous tente et que vous connaissez un site ou une application pour ça, faites-m’en part. Une fois qu’on aura tous signé, j’enverrai le tout aux principaux intéressés.

Lire la Suite »]]> Voilà, notre série d’articles consacrée à la mise en place d’un cloud personnel nous permettant de nous affranchir des solutions propriétaires en ayant recours uniquement à des Logiciels Libres touche à sa fin. Vous disposez désormais d’un ensemble d’outils performants, sécurisés, fiables et faciles à entretenir. Vous avez votre cloud !

Pour y voir un peu plus clair, je vous propose, à travers ce dernier article, de faire le point sur ce que nous avons fait, sur ce qui est en place, et sur ce qui peut encore être optimisé dans le futur.

Articles publiés, sommaire

• Créer son propre Cloud : Introduction
• Installer et configurer un serveur DNS
• Création de sa propre autorité de certification
• Installation de son propre serveur mail
• Installation d’un serveur HTTP/HTTPS
• Kronolith : une alternative à Google Calendar
• Communiquer via XMPP
• Son propre réseau social avec status.net
• Partager ses fichiers sur les réseaux sociaux avec SMP
• Une alternative à Dropbox
• Gérer ses photos avec PhotoShow
• Renforcer la sécurité de son serveur
• Trucs et astuces pour son serveur privé
• Sauvegarder et restaurer son serveur

Ports réseaux

En toute logique, depuis l’extérieur, tous les ports de votre serveur sont fermés, à l’exception des ports suivants :

Applications installées

• Apache (serveur HTTP et HTTPS + Webdav)
• Bind (serveur DNS)
• MySQL (base de données)
• Postfix (serveur SMTP et SMTPS)
• Dovecot (serveur IMAP et IMAPS, gestion des filtres sieve)
• Prosody (serveur XMPP et BOSH)
• Unison (synchronisation)
• fail2ban (sécurisation)
• rsync (sauvegarde)

Applications web installées

• phpMyAdmin (gestion de la base de données)
• RoundCube (client mail)
• Horde + Kronolith (agenda partagé)
• Jappix (client XMPP)
• Status.net (réseau social)
• SMP (partage de fichiers sur les réseaux sociaux)
• Horde + Gollem (accès aux fichiers)
• PhotoShow (galerie de photos)
• phpSysInfo (monitoring)

Améliorations, ajouts

En l’état, vous disposez d’une base, bien fournie mais une base tout de même à laquelle on peut ajouter beaucoup d’autres choses :

• un serveur de streaming audio/vidéo
• des serveurs de jeux comme Minecraft ou Half Life qui offrent un serveur natif GNU/Linux
• des scripts plus personnalisés
• d’autres applications web (blog, agrégateur de contenu, syndication, utilitaires de la vie courante)
• la gestion d’un onduleur
• j’aurai aimé compléter l’article sur XMPP en rajoutant des astuces pour l’intégration avec postfix/dovecot pour la notification de nouveaux messages ou pour un monitoring interactif du serveur, mais je n’ai pas eu le temps de tester moi-même
• et probablement d’autres choses qui ne me viennent pas immédiatement à l’esprit

Remerciements

Je remercie :

• tous mes lecteurs qui ont contribué de près ou de loin à la rédaction de ces articles
• les bloggeurs qui m’ont linké
• mes followers, qu’ils soient sur twitter, facebook ou status.net
• Coca Cola et Red Bull (qui auraient pu me fournir quelques canettes gracieusement, franchement…)
• ma femme qui m’a supporté
• mes chats qui ne sont pas montés sur le bureau trop souvent pendant que j’écrivais
• mes PC qui ne m’ont pas lâché pendant que je les torturais
• l’Allemagne qui ne signe pas ACTA
• mes parents sans qui je ne serai pas là aujourd’hui
• ceux qui riront en lisant mes remerciements, particulièrement celle concernant mes parents

Continuez de m’écrire, me linker et m’aider. Vous me donnez un but en le faisant : contribuer aux communautés du Libre !

Lire la Suite »]]> Maintenant que nous disposons d’un serveur pratiquement complet pour avoir son propre cloud, que nous avons renforcé sa sécurité et que nous avons vu comment opérer un monitoring basique, nous allons voir comment sauvegarder et restaurer son serveur.

Nous allons faire appel au fameux rsync, pour ne pas encombrer notre serveur de solutions aussi lourdes à installer qu’à configurer, d’autant que je vous propose un script qui va simplifier tout ça, et même plus encore…

Vous pouvez placer ce script n’importe où : sur le serveur qui héberge vos services, sur votre propre machine, sur un serveur séparé, un NAS qui supporte rsync et l’authentification par clé, etc. Il suffit de configurer un peu le script pour que la sauvegarde se fasse presque toute seule. Elle est pas belle la vie Libre ?

Choisir son dispositif de stockage

Communément, on sauvegarde sur une partition séparée, de préférence sur un disque séparé, peut être dans une machine séparée, ultimement dans un local séparé. Il n’y a véritablement que deux prérogatives à l’utilisation du script que je vous propose : la machine doit pouvoir utiliser rsync, et l’authentification par clé. Toute distribution GNU/Linux en est capable, vous ne devriez donc pas avoir trop de mal à disposer d’une plateforme adéquate.

Évidemment, une autre prérogative s’impose d’elle-même : l’espace disque disponible.

À titre d’exemple, sachez que j’utilise ce script pour sauvegarder deux serveurs et les documents d’une dizaine de personnes. Le premier, celui qui héberge ingnu.fr, héberge aussi tout un tas d’autres sites, un serveur mail d’une dizaine d’utilisateurs, les bases de données, etc. Au total, un snapshot des deux machines occupe à l’heure actuelle 7.6Go.

Mon script vous permet de disposer de deux types de sauvegardes : un instantané (appelé snapshot) et un instantané de chaque heure de chaque jour. Le premier instantané est en réalité vieux au maximum d’une minute, tandis que les autres instantanés vous permettent de remonter dans le temps par tranche d’une heure, sur un nombre de jours que vous pouvez déterminer.

Au final, sur cinq jours (qui est le réglage par défaut), l’espace disque total occupé par les sauvegardes n’est que doublé : il est actuellement de 13Go. Seuls les fichiers modifiés occupent la différence entre l’espace total et l’espace initial.

Vous n’avez donc pas besoin d’un disque de plusieurs téraoctets, à moins que vous ne vouliez sauvegarder aussi des fichiers comme des vidéos ou des distributions GNU/Linux en quantité industrielle…

Créer la clé d’authentification

La communication entre le serveur et la machine qui exécute la sauvegarde (qui peut aussi être la même machine donc) se fait via rsync, donc ssh. La connexion est par conséquent chiffrée, et les transferts sont intelligents : la bande passante est minimisée.

Pour pouvoir tout sauvegarder d’un coup, on va donc sauvegarder en tant que root. Si vous sauvegardez depuis une machine distante, créez une clé avec la commande suivante :

ssh-keygen -t rsa -f ~/.ssh/id_rsa_backup

Que vous enverrez au serveur via la commande :

ssh-copy-id -i ~/.ssh/id_rsa_backup.pub root@exemple.fr

Vous devrez saisir le mot de passe root de la machine distante. Testez enfin l’accès :

ssh root@exemple.fr

Vous devriez être connecté sans avoir eu besoin de saisir votre mot de passe.

Créer le script de sauvegarde

Créez un répertoire dédié au script et à sa configuration :

mkdir -p /scripts/backup
cd /scripts/backup
mkdir conf.d include.d exclude.d

Pour respecter le Standard de Hiérarchie des Systèmes de Fichiers, nous devrions placer le script dans /usr/bin, et la configuration dans /etc/backup. Rien ne vous empêche de procéder de la sorte, à condition de modifier les chemins d’accès dans le script que nous allons voir tout de suite :

nano backup

#!/bin/bash

###############################################################################
# Variables                                                                   #
###############################################################################

my_pid=$$
my_dir=$(dirname $0)
pid_file="/var/run/backup.pid"

conf_dir="$my_dir/conf.d"
include_dir="$my_dir/include.d"
exclude_dir="$my_dir/exclude.d"

log_dir="/var/log/backup"
log_file="$log_dir/backup"

rsync_args="--archive --recursive --delete --delete-excluded"

backup_root="/mnt/backup"

rsync=$(which rsync)

current_date=$(date "+%Y-%m-%d")
current_minute=$(date +%M)
current_hour=$(date +%H)
yesterday_date=$(date --date "yesterday" "+%Y-%m-%d")

max_age=5
oldest_backup=$(date --date "$max_age days ago" "+%Y-%m-%d/%H")
oldest_log=$(date --date "$max_age days ago" "+%Y-%m-%d")

###############################################################################
# Fonctions                                                                   #
###############################################################################

function check_pid() {
    if [ -f "$pid_file" ]
    then
        old_pid=$(cat "$pid_file")
        old_pid_exists=$(ps -p $old_pid | grep -v TTY | awk -F " " '{print $1}')

        if [ "$old_pid_exists" != "" ]
        then
            exit
        fi
    fi
}

function log() {
    if [ "$2" == "true" -o "$2" == "TRUE" -o "$2" == "yes" -o "$2" == "YES" -o "$2" == "1" ]
    then
        log_date=$(date "+%d/%m/%Y %H:%M:%S")

        echo "[$log_date] $1" >> "$log_file"
    else
        echo "$1" >> "$log_file"
    fi
}

function check_dir() {
    if [ ! -d "$1" ]
    then
        mkdir -p "$1"
    fi
}

###############################################################################
# Lancement de la procédure                                                   #
###############################################################################

##### Vérification des journaux ###############################################

check_dir "$log_dir"

if [ ! -f "$log_file" ]
then
    touch "$log_file"
fi

##### Déplacement des anciens journaux ########################################

if [ "$current_hour" == "00" -a "$current_minute" == "00" ]
then
    mv "$log_file" "$log_file-$yesterday_date"
fi

##### Démarrage de la procédure ###############################################

check_pid

echo $my_pid > "$pid_file"

start_date=$(date "+%d/%m/%Y %H:%M:%S")

log " "
log "###############################################################################"
log "# Début de la procédure : $start_date                                 #"
log "###############################################################################"
log " "

list=$(ls "$conf_dir")

for host in $list; do
    conf_file="$conf_dir/$host"

    source "$conf_file"

    host_rsync_args="$rsync_args"
    host_snapshot="$backup_root/$host/snapshot"

    if [ "$ENABLED" != "yes" -a "$ENABLED" != "YES" -a "$ENABLED" != "true" -a "$ENABLED" != "TRUE" -a "$ENABLED" != "1" ]
    then
        log "**** L'hôte $host est désactivé ****"
        log " "
        continue
    fi

    log "**** Traitement de l'hôte $host ****"
    log " "

    source="$SOURCE"
    target="$host_snapshot"

    check_dir "$target"

    log "Source : $SOURCE" true
    log "Destination : $target" true

    if [ -f "$include_dir/$host" ]
    then
        log "Un fichier d'inclusion existe : $include_dir/$host" true
        host_rsync_args="$host_rsync_args --files-from=$include_dir/$host"
    fi

    if [ -f "$exclude_dir/$host" ]
    then
        log "Un fichier d'exclusion existe : $exclude_dir/$host" true
        host_rsync_args="$host_rsync_args --exclude-from=$exclude_dir/$host"
    fi

    log "Commande : $rsync $host_rsync_args $source $target" true
    log "Démarrage de la création ou mise à jour de l'instantané..." true

    $rsync $host_rsync_args $source $target

    log "Création ou mise à jour de l'instantané terminée" true

    ##### Sauvegarde périodique ###############################################

    if [ "$current_minute" == "00" ]
    then
        log " "
        log "Sauvegarde périodique" true

        source="$host_snapshot/"
        target="$backup_root/$host/$current_date/$current_hour/"

        check_dir "$target"

        log "Source : $source" true
        log "Destination : $target" true
        log "Commande : $rsync $host_rsync_args --links-dest=$source $SOURCE $target" true
        log "Démarrage de la sauvegarde périodique..." true

        $rsync $host_rsync_args --link-dest="$source" "$SOURCE" "$target"

        log "Sauvegarde périodique terminée" true
    fi

    ##### Suppression des anciennes sauvegardes ###############################

    log " "
    log "Recherche d'une ancienne sauvegarde ($backup_root/$host/$oldest_backup)..." true

    if [ -d "$backup_root/$host/$oldest_backup" ]
    then
        log "Une ancienne sauvegarde existe : $backup_root/$host/$oldest_backup" true
        log "Suppression de la sauvegarde la plus ancienne..." true

        rm -rf "$backup_root/$host/$oldest_backup"

        log "Suppression terminée" true
    else
        log "Il n'existe pas d'ancienne sauvegarde" true
    fi

    log " "
done

end_date=$(date "+%d/%m/%Y %H:%M:%S")

log "###############################################################################"
log "# Fin de la procédure : $end_date                                   #"
log "###############################################################################"
log " "

rm -f "$pid_file"

Quelques explications. Si vous voulez respecter les FHS, modifiez les variables conf_dir, include_dir et exclude_dir. Vous pouvez également modifier la variable max_age, dont la valeur (un entier) représente le nombre de jours à conserver.

Ensuite, quelques fonctions classiques : recherche d’un pid existant (pour ne pas lancer deux sauvegardes simultanées), journalisation, et recherche et création de répertoire.

La procédure commence alors par la vérification de l’existence des journaux et leur archivage. Puis, le script récupère la liste des fichiers contenus dans conf.d, lit chacun d’entre eux pour obtenir deux directives de configuration ($ENABLED true/false et $SOURCE représentant la source à sauvegarder), recherche s’il existe un fichier d’inclusion (il vaut mieux sinon vous sauvegardez toute la partition, se trouve dans le répertoire include.d) et un fichier d’exclusion (facultatif, se trouve dans exclude.d).

Chaque minute (via une tâche cron), le script se lance, et créé ou met à jour l’instantané (le contenu du répertoire $backup_root/$host/snapshot). Chaque heure, ce snapshot est créé dans un répertoire distinct, en faisant appel aux hard links : le fichier n’est pas copié, mais un hard link est créé. Autrement dit, le fichier est accessible depuis deux adresses différentes. Même si la source (dans le snapshot) est supprimée, le fichier existe toujours grâce au hard link. Dans notre cas, cela nous permet d’économiser de l’espace disque.

La conséquence de cette façon de procéder est de disposer à tout instant d’une image complète du système de fichiers sauvegardé. Et le but, c’est de le restaurer en une ligne de commande (une simple copie suffira).

Enfin, on supprime les instantanés les plus anciens.

Attribuez le droit d’exécution au script :

chmod +x backup

Configuration

Vous disposez donc d’un répertoire conf.d, include.d et exclude.d. Le premier contiendra un fichier par machine à sauvegarder. Vous pouvez nommer ce fichier comme bon vous semble. Une seule règle à respecter : ce nom devra être le même que celui du fichier d’inclusions et du fichier d’exclusions.

Créons la configuration de notre cloud :

nano conf.d/my_cloud

ENABLED=true
SOURCE=/

Si le serveur est une machine différente, on utilisera la notation suivante :

SOURCE="root@exemple.fr:/"

Avec cette configuration, on va sauvegarder l’ensemble de la machine concernée (ou plus exactement, l’intégralité de la partition /). Ce n’est probablement pas ce que vous voulez, alors nous devons créer un fichier d’inclusions :

nano include.d/my_cloud

À peu de chose près, vous devriez mettre ceci :

/etc/amavis
/etc/apache2
/etc/bind
/etc/clamav
/etc/dovecot
/etc/php5
/etc/postfix
/etc/prosody
/etc/rc.local
/etc/spamassassin
/etc/ssl
/opt
/scripts
/var/vmail
/var/www
/var/lib/mysql

Avec ce contenu, vous devriez sauvegarder l’intégralité du serveur que nous avons configuré jusqu’à maintenant.

Pour éviter de sauvegarder des choses inutiles, créons un fichier d’exclusions :

nano exclude.d/my_cloud

log

Lancement

On édite la crontab de l’utilisateur qui procède à la sauvegarde :

crontab -e

* * * * * /scripts/backup/backup

Et on vérifie le contenu du journal :

tail -f /var/log/backup/backup

Restauration

Pour restaurer votre serveur, il suffit de copier vers lui tout ou partie de la dernière sauvegarde valide, via scp, tout simplement. Inutile de tergiverser : grâce à ce système de sauvegarde, il suffit d’une simple copie sécurisée pour restaurer le dernier état valide du serveur ; contrairement à d’autres solutions de sauvegarde, pas besoin d’installer un agent sur la machine distante, une simple connexion ssh suffit !

Conclusion

Nous voici arrivés à la fin de la série d’articles sur la création de son cloud personnel. Plus qu’un article à publier d’ici quelques minutes, alors à tout de suite !

Lire la Suite »]]> Je l’ai dis il y a quelques dizaines de minutes sur social.ingnu, j’abandonne facebook et twitter. Bien que ma principale raison soit évidemment liée à la protection de ma vie privée, il en existe d’autres.

Tout d’abord, facebook et twitter ont beau cumuler à eux deux une population plus nombreuse que la Chine, je m’y sens seul. J’ai l’impression qu’il n’y a aucune activité qui m’intéresse. C’est d’autant plus vrai en ce qui concerne facebook, dont l’idée est davantage de se constituer un cercle d’amis plutôt qu’échanger des idées réellement intéressantes. Je commence à me lasser des photos personnelles, des histoires d’horoscope, ou de ce que les gens ont bouffé la veille (je ne parle pas de mes propres contacts qui ont des timelines un peu plus développées). Ce que je veux dire, c’est que trouver des gens qui m’intéressent sur facebook tient plus du hasard qu’autre chose. D’ailleurs, en fait, ce n’est jamais arrivé.

En ce qui concerne twitter, la situation est différente. La limite à 160 caractères (ou 144 je ne sais plus) est parfaitement incompréhensible pour moi. On est à l’ère du haut débit, où on s’échange des photos en quelques secondes, des films en quelques minutes. La limite de caractères arbitrairement imposée par twitter engendre des posts parfaitement incompréhensibles, truffés de raccourcis et d’abréviations qui pourrissent la timeline, d’autant que cela nécessite de faire le tri entre l’information qui est intéressante de celle qui ne l’est pas. C’est une perte de temps.

Il y a quelques semaines, j’ai franchi le pas et j’ai installé une instance de status.net. Je l’ai installé parce que c’est un Logiciel Libre, et qu’il est présenté comme un réseau social libre et décentralisé. J’en avais déjà entendu parlé, mais j’étais un peu frileux, n’étant pas de nature particulièrement sociable.

En fin de compte, je me suis rendu compte que l’ouverture de cette application n’est pas seulement une philosophie de développement : cette ouverture se fait aussi sur le monde, à un niveau que je ne soupçonnais pas. On ne suit pas seulement des gens, individuellement, on suit des groupes, des fédérations d’instances de status.net. Et là, ça s’emballe : je reçois les posts de plusieurs dizaines de personnes simplement parce que je suis le groupe Debian, ou le groupe GNU. Et le ratio informations intéressantes/inutiles s’inverse par rapport aux autres réseaux sociaux (je ne parle pas de Google+ que j’ai quitté il y a quelques temps).

Du coup, on peut communiquer avec beaucoup plus de gens que sur facebook ou twitter, et surtout, beaucoup plus de gens qui partagent les mêmes centres d’intérêt.

Je n’ai pas encore bien pris le temps de m’occuper de mes followers ou de ceux que je follow, ce qui fait que ma liste est relativement restreinte. Mais j’ai déjà l’impression que c’est un nouveau monde qui s’étend à mes pieds – à mes doigts. Je me sens comme un explorateur qui vient de découvrir une terre inconnue, qui n’a qu’une hâte : l’explorer. D’autant que cette terre est déjà bien peuplée, vivante, comme si elle avait toujours été là.

Ce qui me permet de rebondir sur une critique que j’ai parfois entendu : non, ce n’est pas mort, non, ce n’est pas dépeuplé. C’est au contraire très actif, et de manière beaucoup plus intelligente que les autres réseaux sociaux.

Par un mystère que je ne m’explique pas, j’ai l’impression que des étrangers communiquent plus facilement sur status.net que sur n’importe quel autre réseau social. En ce qui concerne twitter, c’est peut être dû au fait que la communication est essentiellement uni-directionnelle, et concernant facebook, peut-être parce qu’il n’y a de communication que sur soi-même.

Sur status.net, c’est l’esprit Libre : on échange, on partage, on communique de manière omnidirectionnelle. Il suffit de faire partie d’un groupe pour que tous puissent lire ce que vous écrivez, tandis que vos posts (vos notices) ne quittent pas votre serveur.

Si vous faites partie de mes contacts facebook ou twitter, et que vous ne faites pas encore partie de mes contacts sur social.ingnu, je vous recommande donc chaudement de venir me rejoindre. Créez-vous un compte sur mon instance (ou sur identi.ca par exemple), et ajoutez ingnu@social.ingnu.fr à ceux que vous suivez.

Peut-être alors qu’un jour, vous aussi vous quitterez les réseaux sociaux riches à milliards qui se servent de vos informations personnelles pour y parvenir, pour revenir du côté lumineux de la Force…

Lire la Suite »]]> Avant d’aborder un système de sauvegarde et de restauration pour son cloud personnel, je me suis dis que ce serait une bonne idée de compiler dans un article quelques trucs et astuces, relatifs notamment à la surveillance de votre serveur.

C’est l’occasion d’apprendre ou réapprendre à se servir des outils inclus dans toute bonne distribution qui se respecte, mais aussi comment compléter ces outils.

Monitoring « sur site »

Journaux

Ce que j’appelle « monitoring sur site », c’est comment surveiller son système depuis un shell. Un certain nombre de commandes existent pour nous permettre de diagnostiquer le fonctionnement de notre serveur.

Pour commencer, rien ne vaut les journaux. Concernant notre serveur, voici ceux qui sont principalement à surveiller :

• /var/log/syslog, probablement le plus important de tous
• /var/log/fail2ban.log, pour surveiller ce que fail2ban fait
• /var/log/mail.log, pour surveiller le serveur mail
• /var/www/*/*/log/, pour surveiller les accès et erreurs sur l’ensemble de vos sites Internet

Pour consulter en temps réel un journal, utilisez la commande suivante :

tail -f /var/log/syslog

Pour consulter les X dernières lignes d’un journal :

tail -X /var/log/syslog

Processus

Le monitoring sur site implique également la surveillance des processus. La commande suivante :

ps aux

Vous indiquera l’état des processus au moment où vous lancez la commande. Pour consulter l’état des processus en temps réel, utilisez la commande :

top

Cette commande vous informe également de l’état de la mémoire, de l’utilisation CPU, et d’autres choses encore.

Matériel

Si vous hébergez vous-même votre serveur « à la maison », vous pourrez également avoir besoin de quelques capteurs de température :

apt-get install lm-sensors
sensors-detect

De même pour les disques durs :

apt-get install hddtemp
hddtemp /dev/sd*

D’autres informations relatives à votre matériel peuvent être extraites du pseudo système de fichiers /proc :

cat /proc/cpuinfo
cat /proc/meminfo

RAID

Si vous bénéficiez d’un raid logiciel, vous pouvez consulter son état de différentes manières :

cat /proc/mdstat
mdadm --detail /dev/md0

Monitoring distant

Le monitoring distant est effectué depuis une interface web par exemple. J’ai choisi phpSysInfo, que je trouve plus agréable à configurer et utiliser que munin, trop centré sur la création de graphs, et relativement compliqué à mettre en œuvre.

Hôte virtuel

Première chose, comme d’habitude, on s’occupe de l’hôte virtuel dans apache :

mkdir -p /var/www/exemple.fr/system/www
nano /etc/apache2/sites-available/system.exemple.fr

<VirtualHost *:80>
	ServerName system.exemple.fr
	Redirect / https://system.exemple.fr/
</VirtualHost>

<VirtualHost *:443>
	ServerName system.exemple.fr

	DocumentRoot /var/www/exemple.fr/system/www

	SSLEngine On
	SSLCertificateFile /scripts/certificate_authority/apache/system.exemple.fr.crt
	SSLCertificateKeyFile /scripts/certificate_authority/apache/system.exemple.fr.key
</VirtualHost>

Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe. Créons maintenant les certificats :

/scripts/certificate_authority/make_request apache system.exemple.fr
/scripts/certificate_authority/sign_request apache system.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*

On active le site, et on redémarre apache :

a2ensite system.exemple.fr
/etc/init.d/apache2 restart

Dans ce cas, il n’y a pas vraiment besoin de tenir des journaux.

Installation de phpSysInfo

Rien de particulier à signaler : une fois l’application téléchargée et installée dans son répertoire (/var/www/exemple.fr/system/www), il suffit juste de la configurer en fonction des blocs que vous souhaitez afficher.

Certaines dépendances peuvent être nécessaires, en fonction des blocs que vous aurez configuré. L’application vous informera via des messages d’erreurs si des dépendances ne sont pas satisfaites. Vous pourrez alors aisément les installer.

Notifications

Si vous faites appel à crontab pour effectuer des tâches routinières, il peut être intéressant d’avoir des rapports par mail. Il vous suffit d’éditer votre crontab et d’y insérer la ligne suivante :

MAIL="contact@exemple.fr"

Nous avons installé un serveur XMPP, on peut également s’en servir comme service de notification. Ainsi, pour toute application qui permet d’exécuter une commande suivant un évènement donné, on peut demander à cette application d’envoyer un message à un compte XMPP que vous aurez créé à cet effet. Nous utiliserons pour cela le script sendxmpp :

apt-get install sendxmpp

Que l’on utilisera de la manière suivante :

echo "Votre message" | sendxmpp -u <utilisateur> -p <mot de passe> -j exemple.fr <destinataire>@exemple.fr

Liste des paquets installés

Il peut être utile de récupérer la liste de tous les paquets installés, par exemple dans le cas d’une réinstallation ou d’un mirroring. Pour récupérer cette liste, on utilisera la commande suivante :

dpkg -l | grep ii | awk -F ' ' '{print $2}'

On peut, du coup, exporter cette liste dans un fichier :

dpkg -l | grep ii | awk -F ' ' '{print $2}' > packages.list

Conclusion

Plein d’autres choses manquent surement à l’appel. On ne peut pas tout voir, mais théoriquement, ce qu’on a vu jusqu’aujourd’hui devrait être suffisant pour que vous puissiez jouer avec votre propre cloud.

Lire la Suite »]]> Nous voilà sur la dernière ligne droite de notre série d’articles consacrée à la mise en place d’un cloud personnel. Nous avons installé à peu près tout ce dont on peut avoir besoin, mais à part un script de pare-feu relativement restrictif et une protection anti-spam et anti-virus pour le serveur mail, il reste encore quelques petites choses à faire pour sécuriser notre serveur.

Avant toute chose, contrairement à ce que beaucoup de gens recommandent comme bonne pratique, je ne vais pas aborder la question du changement de port pour améliorer la sécurité de notre serveur. Je pense en effet qu’un simple nmap sur l’hôte à tester suffit pour déterminer quels sont les ports ouverts sur une machine, et ce n’est pas en déplaçant ce port que le « pirate » va jeter l’éponge. Si quelqu’un est vraiment déterminé à récupérer de votre serveur des données auxquelles il n’a pas le droit d’accéder, il y parviendra.

Je mise donc sur une approche différente qu’on va tout de suite mettre en place, et qui repose sur fail2ban. Pour mémoire, fail2ban analyse les tentatives de connexion à votre serveur, et blacklist toute IP qui tentera d’accéder à votre serveur sans succès, selon un certain nombre de règles (qui peuvent être bien velues à configurer…).

fail2ban

Installons l’application :

apt-get install fail2ban
/etc/init.d/fail2ban stop

On configure ensuite l’application :

mv /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf-orig
nano /etc/fail2ban/jail.conf

Le nombre d’applications nécessitant une connexion réseau pour fonctionner est relativement limité sur notre serveur, ce qui va simplifier la configuration de fail2ban, d’autant que la plupart des filtres existe déjà.

Voici un fichier jail.conf de référence, correspondant à notre serveur :

[DEFAULT]
ignoreip = 127.0.0.1 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
bantime = 600
maxretry = 3
backend = polling
destemail = contact@exemple.fr
banaction = iptables-multiport
mta = sendmail
protocol = tcp

action_ = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]

action_mw = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
              %(mta)s-whois[name=%(__name__)s, dest="%(destemail)s", protocol="%(protocol)s]

action_mwl = %(banaction)s[name=%(__name__)s, port="%(port)s", protocol="%(protocol)s]
               %(mta)s-whois-lines[name=%(__name__)s, dest="%(destemail)s", logpath=%(logpath)s]

# Choose default action.  To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g.  action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_)s

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 6

[ssh-ddos]
enabled = false
port    = ssh
filter  = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 6

[pam-generic]
enabled = true
filter  = pam-generic
port = all
banaction = iptables-allports
port     = anyport
logpath  = /var/log/auth.log
maxretry = 6

[apache]
enabled = true
port    = http,https
filter  = apache-auth
logpath = /var/www/*/*/log/error.log
maxretry = 6

[apache-multiport]
enabled   = true
port      = http,https
filter    = apache-auth
logpath   = /var/www/*/*/log/error.log
maxretry  = 6

[apache-noscript]
enabled = true
port    = http,https
filter  = apache-noscript
logpath = /var/www/*/*/log/error.log
maxretry = 6

[apache-overflows]
enabled = true
port    = http,https
filter  = apache-overflows
logpath = /var/www/*/*/log/error.log
maxretry = 2

[postfix]
enabled  = true
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log

[sasl]
enabled  = true
port     = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter   = sasl
logpath  = /var/log/mail.log

[named-refused-tcp]
enabled  = true
port     = domain,953
protocol = tcp
filter   = named-refused
logpath  = /var/log/named/security.log

Si vous activez le monitoring pour bind, vous devez activer la journalisation :

nano /etc/bind/named.conf.options

logging {
     channel security_file {
         file "/var/log/named/security.log" versions 3 size 30m;
         severity dynamic;
         print-time yes;
     };
     category security {
         security_file;
     };
};

/etc/init.d/bind9 restart

Vous devriez être relativement tranquille avec ce fichier de configuration.

Démarrez ensuite le service :

/etc/init.d/fail2ban start

Désormais, si quelqu’un n’entre pas dans les clous, son adresse IP sera bloquée directement au niveau d’iptables, pour une durée déterminée spécifiée en début de fichier de configuration.

Un firewall « modulaire »

On va un peu compléter notre script de pare-feu pour vous permettre de spécifier vous-même une liste d’adresses IP à bannir.

nano /scripts/firewall

Ajoutez tout à la fin du fichier :

if [ -f "/scripts/firewall.hosts" ]
then
    for ip in `cat /scripts/firewall.hosts`; do
        ${IPT} -A INPUT -s $ip -j DROP
    done
fi

Créez ensuite le fichier en question :

touch /scripts/firewall.hosts

Vous pouvez maintenant remplir ce fichier avec les adresses IP que vous souhaitez bloquer (une par ligne).

N’oubliez pas de relancer le script une fois vos modifications terminées :

/scripts/firewall

Accès via certificats clients

Si vous le souhaitez, vous pouvez limiter l’accès à certains de vos sites Internet à certains clients disposant d’un certificat délivré par vous-même.

Il suffit de modifier le fichier de configuration de l’hôte virtuel que vous voulez « protéger », en rajoutant les lignes suivantes :

<Location />
    SSLCACertificateFile /scripts/certificate_authority/ca.crt
    SSLVerifyClient require
    SSLVerifyDepth 4
</Location>

Vous créez ensuite un certificat classique :

/scripts/certificate_authority/make_request apache-client sous-domaine.exemple.fr
/scripts/certificate_authority/sign_request apache-client sous-domaine.exemple.fr
chown -R www-data:www-data /scripts/certificate_authority/apache-client

Il faut ensuite exporter le certificat créé et signé dans un format compatible :

openssl pkcs12 -export -clcerts -in /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.crt -inkey /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.key -out /scripts/certificate_authority/apache-client/sous-domaine.exemple.fr.p12

Transmettez ce certificat et son mot de passe au client qui doit accéder au site, client qui devra l’importer dans son navigateur. Utilisez de préférence SSH pour effectuer ce transfert

Lire la Suite »]]> Maintenant que nous disposons d’une solution de stockage en ligne, la prochaine étape consistera à mettre en place une application web pour partager ses photos avec le reste du monde.

Bien que de très nombreuses solutions existent, et de très bonne qualité (voir mon article sur les alternatives à Google), mon choix s’est porté sur une petite application du nom de PhotoShow.

Je l’ai choisi pour plusieurs raisons. Tout d’abord, elle ne nécessite aucune base de données. Ensuite, elle ne nécessite pratiquement aucune maintenance, dans la mesure où les photos sont analysées automatiquement. Est également automatique la génération des miniatures. Et malgré sa simplicité, il reste possible de définir tout ou partie de la galerie comme étant privée, dont l’accès sera réservé aux utilisateurs de votre choix, ou simplement protégé par mot de passe.

Enfin, l’arborescence des fichiers n’a pas besoin de se trouver dans l’arborescence du site. Cela permet d’éviter que n’importe qui (les moteurs de recherche par exemple) puisse aspirer sans vergogne vos photos. On respecte ainsi une autre prérogative de ma série d’articles : préserver la confidentialité de nos données.

Hôte virtuel

Première chose, comme d’habitude, on s’occupe de l’hôte virtuel dans apache :

nano /etc/apache2/sites-available/photos.exemple.fr

<VirtualHost *:80>
	ServerName photos.exemple.fr
	Redirect / https://photos.exemple.fr/
</VirtualHost>

<VirtualHost *:443>
	ServerName photos.exemple.fr

	DocumentRoot /var/www/exemple.fr/photos/www

	SSLEngine On
	SSLCertificateFile /scripts/certificate_authority/apache/photos.exemple.fr.crt
	SSLCertificateKeyFile /scripts/certificate_authority/apache/photos.exemple.fr.key

        CustomLog /var/www/exemple.fr/photos/log/access.log
        ErrorLog /var/www/exemple.fr/photos/log/error.log
</VirtualHost>

Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe. Créons maintenant les certificats :

/scripts/certificate_authority/make_request apache photos.exemple.fr
/scripts/certificate_authority/sign_request apache photos.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*

On active le site, et on redémarre apache :

a2ensite photos.exemple.fr
/etc/init.d/apache2 restart

Installation de PhotoShow

On créé l’arborescence du site :

mkdir -p /var/www/exemple.fr/photos/{www,log,thumbs}

Puis on télécharge et on installe PhotoShow :

cd /usr/src
git clone git://github.com/thibaud-rohmer/PhotoShow.git
cp -R PhotoShow/* /var/www/exemple.fr/photos/www/
chown -R www-data:www-data /var/www/exemple.fr/photos

On configure l’application :

nano /var/www/exemple.fr/photos/www/config.php

$config->photos_dir   = "/var/public-docs/Photos";
$config->ps_generated   = "/var/www/exemple.fr/photos/thumbs";

Vous noterez le répertoire /var/public-docs/Photos qu’il faut créer, et qui contiendra donc vos photos.

mkdir /var/public-docs/Photos

L’application en elle-même est prête, vous pouvez la visiter depuis l’adresse http://photos.exemple.fr.

Vous pouvez créer un compte « anonyme« , ou « invites« , protégé par mot de passe, si vous ne voulez pas que des personnes non identifiées aient accès à votre galerie. Vous pouvez aussi simplement la protéger avec un mot de passe, sans avoir besoin de créer un utilisateur particulier.

Envoyer automatiquement ses photos prises avec un smartphone Android

Facile, si vous avez installé l’application WebDav File Manager comme indiqué dans mon précédent article (ou toute autre application Android capable de se synchroniser avec un dépôt WebDav ou SSH). Il vous suffit de mettre en place une synchronisation entre le répertoire où vos photos sont stockées sur votre smartphone (DCIM/) et https://files.exemple.fr/public/Photos.

Le tutoriel d’aujourd’hui est déjà terminé. Nous avons vu des choses relativement compliquées à mettre en oeuvre, mais c’était aussi pour nous simplifier la vie plus tard. Je vous avais bien dis que les prochains articles seraient plus simples !

Lire la Suite »]]> Je sais qu’il y a beaucoup de sources d’informations pour savoir ce qu’est le Libre (dont la principale), mais j’ai toujours constaté avec regret qu’il y a encore beaucoup de gens qui considèrent mal les Libristes, les défenseurs du Libre.

Je les ai vu dire que dans certains domaines, les Logiciels Libres n’arrivent pas à la cheville des logiciels privateurs, sur le plan technique. J’en ai vu dire que les Logiciels Libres n’apportent rien, et ne sont d’aucune utilité face aux logiciels privateurs. J’en ai vu dire que les Logiciels Libres ne sont pas des alternatives viables aux logiciels privateurs, ou aux services web du type Google ou facebook. J’en ai même lu qui disaient que si un auteur de Logiciel Libre voulait insérer dans son code une partie destinée à espionner l’utilisateur, personne ne le verrait.

Alors, j’ai décidé d’essayer autre chose, que dire « les Logiciels Libres c’est mieux, les logiciels privateurs c’est mal ».

La plupart des critiques que j’ai lu sont fondées sur l’aspect technique des Logiciels Libres. Or, le fondement même des Logiciels Libres est la liberté justement. Ils n’existent pas simplement pour qu’une alternative à Microsoft Office ou Microsoft Windows existe, ils existent pour apporter la liberté au sein de l’informatique. Ils ont été conçus pour libérer leurs utilisateurs des contraintes arbitrairement et injustement imposées par les éditeurs de logiciels.

C’est à Richard Stallman que l’on doit cette vision du Logiciel Libre. Tout défenseur du Logiciel Libre se doit de connaître et approuver Stallman, tandis que ses détracteurs se doivent de connaître les intentions formulées par Licence Publique Générale.

L’aspect technique des Logiciels Libres est pour ainsi dire secondaire : la priorité est d’accorder des libertés fondamentales aux auteurs et aux utilisateurs de ces logiciels ; l’aspect technique ne doit être mis en avant que pour leur valorisation par rapport aux solutions privatrices.

Par exemple, dire que GIMP est une plaisanterie face à Photoshop relève de l’ignorance, puisque cela revient à comparer les deux logiciels sur un plan technique. Or, GIMP n’est pas une réponse technique à Photoshop, c’est une réponse de principe. GIMP existe pour que puisse exister une alternative Libre à Photoshop.

Ce que certains considèrent comme une faiblesse est en réalité une force du Logiciel Libre : puisqu’on veut parler d’aspect technique, la technicité d’un Logiciel Libre est dépendante de sa communauté, forte de plusieurs milliers d’utilisateurs qui sont autant de contributeurs, tandis que la technicité d’un logiciel privateur n’est dépendante que du bon vouloir de l’entreprise qui le publie. Autrement dit, elle n’est motivée que par l’argent.

Ce qui m’amène à poser la question suivante : comment un Libriste peut se considérer comme tel s’il ne voit aucun inconvénient à utiliser une solution privative ?

Lire la Suite »]]> Stocker des données personnelles après d’un prestataire comme Dropbox (ou dans un autre esprit, MegaUpload) est dangereux, et l’actualité nous l’a clairement montré : la fermeture arbitraire du service entraîne non seulement l’inaccessibilité de vos données, mais en plus, dans le cadre d’une opération anti-piratage, cela peut conduire également à la suppression de ces données, de manière tout aussi arbitraire.

La solution est une fois de plus évidente : héberger chez soi un tel service.

Ce que je vais vous proposer va faire grincer des dents ceux qui espèrent lire un tutoriel sur l’installation de SparkleShare ou OwnCloud (d’autres existent bien sûr). Je n’en ferai rien. Mais avant de quitter mon site frustré, laissez-moi juste expliquer mes arguments.

SparkleShare et OwnCloud sont relativement jeunes. Or, on est censés leur confier des données personnelles, qui, a priori, ne peuvent se permettre d’être corrompues ou insécurisées. La jeunesse de ces applications fait que, selon moi, elles présentent des risques de sécurité et de fiabilité.

D’autre part, cela nécessite parfois d’installer des dépendances exotiques ou non-libres : SparkleShare requiert mono. Quant à OwnCloud, son manque de fonctionnalités (dû à sa jeunesse encore une fois) n’en fait pas une solution idéale pour le moment.

Enfin, l’objectif de cette série de tutoriels est aussi de respecter ce qui est probablement le plus célèbre des paradigmes unix : une application pour chaque tâche. Ce qui veut dire que dans cet article nous verrons comment synchroniser nos documents entre plusieurs machines et proposer un accès générique à ces documents, tandis que dans les prochains articles, nous installerons des applications répondant à des besoins spécifiques, comme la gestion de galeries de photos par exemple.

Ce que je veux, c’est remplir toutes les fonctionnalités attendues d’un tel système, en utilisant uniquement des solutions logicielles éprouvées, standards, ne faisant appel à aucune dépendance exotique supplémentaire qui viendrait ralentir le serveur entier. En d’autres termes, ma solution convient tout aussi bien aux petits serveurs pas chers qui ne proposent pas une puissance de calcul importante ou un espace disque conséquent, qu’aux serveurs moins modestes capables de faire bien d’autres choses.

Si vous avez tenu jusque là, alors rappelons ce qu’un système tel que Dropbox propose :

• Un espace de stockage accessible depuis n’importe où
• Transferts intelligents pour économiser la bande passante
• Partage de fichiers
• Accès mobile
• Stockage sécurisé

Rien qui ne soit pas accessible à des Logiciels Libres éprouvés !

Chiffrement

L’intérêt de chiffrer vos données sur le disque de votre serveur peut être sujet à discussion : à quoi bon chiffrer ses données sur le disque du serveur si les communications entre vous-même et votre serveur sont déjà chiffrées ? D’autant que pour que vous puissiez accéder aux données, il faut qu’elles soient déjà déchiffrées sur le serveur. Autrement dit, avant que vous vous y connectiez. C’est notamment le cas lors de l’utilisation d’une partition chiffrée. Et s’il faut systématiquement ouvrir un shell sur le serveur pour mettre le mot de passe destiné à déchiffrer les données, cela va rapidement devenir pénible, notamment dans le cadre d’un accès depuis un Smartphone.

Le chiffrement des données sur le disque du serveur présente un intérêt dans le cas extrêmement improbable où quelqu’un parviendrait à obtenir un accès shell au serveur. Si le disque virtuel qu’on a créé n’est pas chiffré, cette personne pourra librement le consulter. Et si c’est l’État qui saisit votre serveur pour une raison X ou Y, vous êtes dans l’obligation de fournir les moyens nécessaires au déchiffrement du disque. Et si vous feintez de l’oublier, le cassage du chiffrement ne devrait pas être trop long, compte tenu du fait que la loi vous interdit d’utiliser un encodage sur plus de 1024bits. Dans tous les cas, le chiffrement au niveau du disque est inutile, encombrant, lourd, et contraignant.

Voilà mon avis personnel sur la question. Si vous estimez que je me trompe, libre à vous de mettre en place les nombreuses solutions de chiffrement qui s’offrent à vous. N’oubliez juste pas que TrueCrypt n’est pas Libre (Open Source est un terme trompeur qui ne signifie pas Libre au sens strict entendu par Richard Stallman – et moi).

Accès aux données

Pour rappel, on n’accèdera pas directement aux fichiers stockés sur le serveur (à l’exception d’un accès par l’interface web). On stocke les fichiers localement, et on les synchronise avec le serveur. Cela permet de ne pas ralentir la machine locale qui n’a pas besoin d’attendre d’être connectée au serveur pour travailler avec les fichiers, de travailler sur les données locales même si le serveur est inaccessible et de les synchroniser une fois le serveur de retour en ligne, et d’économiser de la bande passante puisque seules les modifications sont synchronisées.

Pour permettre plus de souplesse, on va stocker les documents des utilisateurs dans leur répertoire personnel, et proposer un répertoire public, accessible plus exactement à tous ceux ayant un compte sur le serveur.

Autrement dit, tout utilisateur qui souhaite avoir ses fichiers sur notre serveur devra avoir un compte Unix local. Cela nous permettra de conserver, lors des synchronisations, les propriétaires, groupes et permissions appliquées à tout fichier.

Accès aux données depuis Apache

On va installer Gollem pour accéder aux fichiers depuis le navigateur.

Gollem est le gestionnaire de fichiers du framework Horde, que nous avons déjà vu lors de l’installation de Kronolith. Si vous avez suivi – comme je l’expliquais – la première partie du tutoriel, vous avez dû installer Horde de manière globale. Vous savez donc qu’il ne sera pas possible d’installer Gollem de la même manière. Plusieurs options s’offrent à nous :

• Installer Gollem dans sa propre instance de Horde
• Fusionner l’agenda avec le gestionnaire de fichiers (en renommant par exemple l’hôte agenda.exemple.fr)
• Installer un autre gestionnaire de fichiers (tel que Ajaxplorer et eXtplorer)

Il faut savoir concernant ce dernier point que, à ma connaissance et contrairement à Gollem, les autres gestionnaires de fichiers en ligne ne permettent pas d’avoir recours à des comptes Unix, ce qui est un pré-requis pour conserver les propriétaires, groupes et droits sur les fichiers, pré-requis que nous pourrions remplir en ayant recours à une couche FTP, le gestionnaire de fichiers devenant un simple client FTP pour l’hôte local. Inutile, puisque nous n’utiliserons pas FTP à l’extérieur du serveur…

Il faut aussi savoir que si vous optez pour la deuxième solution, les personnes ayant accès à l’agenda auront aussi accès aux fichiers et vice-versa.

Nous retiendrons donc la première solution.

Nous allons créer un hôte virtuel sécurisé, comme on a maintenant l’habitude de faire, à la différence que nous allons recourir à l’authentification par certificat en plus du chiffrement. Cela va vous permettre de contrôler finement l’accès à vos fichiers depuis l’interface web : pour y accéder, il sera obligatoire de disposer d’un certificat client que vous seul pourrez délivrer.

Créons l’arborescence, puis notre hôte virtuel :

mkdir -p /var/www/exemple.fr/files/{log,www}
nano /etc/apache2/sites-available/files.exemple.fr

<VirtualHost *:80>
	ServerName files.exemple.fr
	Redirect / https://files.exemple.fr/
</VirtualHost>

<VirtualHost *:443>
	ServerName files.exemple.fr

	DocumentRoot /var/www/exemple.fr/files/www

	SSLEngine On
	SSLCertificateFile /scripts/certificate_authority/apache/files.exemple.fr.crt
	SSLCertificateKeyFile /scripts/certificate_authority/apache/files.exemple.fr.key

        CustomLog /var/www/exemple.fr/files/log/access.log
        ErrorLog /var/www/exemple.fr/files/log/error.log

        php_value include_path /var/www/exemple.fr/files/pear/php
        SetEnv PHP_PEAR_SYSCONF_DIR /var/www/exemple.fr/files
</VirtualHost>

Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe. Créons maintenant les certificats :

/scripts/certificate_authority/make_request apache files.exemple.fr
/scripts/certificate_authority/sign_request apache files.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*

On active le site, et on redémarre apache :

a2ensite files.exemple.fr
/etc/init.d/apache2 restart

On installe ensuite notre instance de PEAR.

pear config-create /var/www/exemple.fr/files/ /var/www/exemple.fr/pear.conf
pear -c /var/www/exemple.fr/files/pear.conf install pear

On installe Horde :

/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf channel-discover pear.horde.org
/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install horde/horde_role
/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf run-scripts horde/horde_role

/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install -a -B horde/horde
cp /var/www/exemple.fr/files/www/config/conf.php.dist /var/www/exemple.fr/files/www/config/conf.php
chown -R www-data:www-data /var/www/exemple.fr/files

Il reste à installer quelques dépendances :

/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install mdb2_driver_mysql

Créez ensuite un utilisateur MySQL (reportez-vous à cet article pour le faire via phpMyAdmin) avec sa base de données. Donnez-lui le nom « Gollem » par exemple.

Pour pouvoir utiliser PAM (et donc les comptes Unix locaux), il faut installer le paquet correspondant :

pecl install pam

Et modifier Horde :

nano /var/www/exemple.fr/files/pear/php/Horde/Auth/Pam.php

Changez la ligne 40 :

if (!Horde_Util::extensionExists('pam')) {

Pour inclure l’extension pam_auth :

if (!Horde_Util::extensionExists('pam') && !Horde_Util::extensionExists('pam_auth')) {

Enregistrez. On doit encore configurer PAM pour être utilisable par Gollem. Tout d’abord, créons un lien symbolique qui permettra de lier le service PAM de PHP au service PAM de la machine :

cd /etc/pam.d
ln -s login php

Ensuite, il faut que l’utilisateur d’Apache (www-data) ait accès au fichier /etc/shadow. Simple :

adduser www-data shadow

Puis redémarrez Apache :

/etc/init.d/apache2 restart

Configurez ensuite Horde exactement de la même manière que lors de l’installation de Kronolith (là encore, reportez-vous à cet article). Changez seulement les paramètres relatifs à la base de données, et dans l’onglet Authentification, affectez la valeur PAM (Pluggable Authentication Modules) authentication à la directive de configuration $conf[auth][driver]. Enregistrez, mais ne vous déconnectez pas encore de l’interface d’administration (vous ne pourriez plus y revenir pour le moment). Installons maintenant Gollem :

/var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install -a -B horde/gollem

Puis corrigez les droits :

chown -R www-data:www-data /var/www/exemple.fr/files/

Retournez dans Horde, dans Administration > Configuration, et générez la configuration de Gollem.

Il faut, en revanche, modifier à la main la configuration relative à l’accès aux données.

cd /var/www/exemple.fr/files/www/gollem/config
mv backends.php backends.php-orig
nano backends.php

<?php 

$backends['documents'] = array(
    'disabled' =--> false,
    'name' => 'Documents',
    'driver' => 'ssh2',
    'hordeauth' => true,
    'params' => array(
        'hostspec' => 'localhost',
        'permissions' => '700'
    ),
    'loginparams' => array(),
    'root' => '/home',
    'home' => $GLOBALS['registry']->getAuth(),
    'attributes' => array(
        'type',
        'name',
        'edit',
        'download',
        'modified',
        'size',
        'permission',
        'owner',
        'group'
    )
);

$backends['public'] = array(
    'disabled' => false,
    'name' => 'Fichiers publics',
    'driver' => 'ssh2',
    'hordeauth' => true,
    'params' => array(
        'hostspec' => 'localhost',
        'permissions' => '755'
    ),
    'loginparams' => array(),
    'root' => '/var/public-docs',
    'home' => '/var/public-docs',
    'attributes' => array(
        'type',
        'name',
        'edit',
        'download',
        'modified',
        'size',
        'permission',
        'owner',
        'group'
    )
);

On créé deux backends : une pour les documents personnels, une pour les documents publics. Il faut donc créer le répertoire qui va bien :

mkdir /var/public-docs
chmod -R 777 /var/public-docs

On attribue tous les droits à ce répertoire pour que n’importe qui puisse y écrire. Gollem s’occupera de mettre les droits à 755 pour chaque fichiers créé, sachant que Gollem permet à tout utilisateur de modifier les droits sur ses propres fichiers.

Il ne reste plus qu’à tester via l’adresse http://files.exemple.fr.

Une fois que tout fonctionne, vous devriez définir un utilisateur Unix qui sera administrateur de Horde.

nano /var/www/exemple.fr/files/www/config/conf.php

Modifiez la ligne :

$conf['auth']['admins'] = array('Administrator');

Et mettez à la place de Administrator le nom de votre utilisateur unix sur votre serveur. Ainsi, en vous connectant à Horde, vous aurez accès à l’interface d’administration.

On dispose maintenant d’un espace privé pour chaque utilisateur, d’un espace public commun, et d’un moyen d’y accéder par un navigateur. Je crois que le plus dur est fait !

Synchronisation des données

Nous utiliserons unison pour synchroniser nos données. L’avantage procuré par unison est qu’il permet une synchronisation bidirectionnelle, tandis que rsync ne propose qu’une synchronisation unidirectionnelle.

Bien que l’application ne soit plus maintenue, elle reste un élément fondamental de notre système : la synchronisation bidirectionnelle est ce qui va nous permettre d’avoir partout les mêmes fichiers, qu’on les ait modifiés depuis l’interface web, une machine sous GNU/Linux, sous Windows ou sous Mac.

Le fait que l’application ne soit plus maintenue devient du coup un avantage. Nous utiliserons donc la dernière version stable : la 2.40.63.

Cette version se trouve dans le dépôt testing de Debian. Si vous ne souhaitez pas ajouter ce dépôt à votre configuration (autrement dit, si vous ne voulez pas vous embêter avec l’apt pinning), vous pouvez télécharger le paquet directement depuis cette page.

Si c’est la voie que vous avez choisi, vous utiliserez dpkg :

dpkg -i unison_2.40.63-2_amd64.deb

Sinon, apt-get :

apt-get -t testing install unison

Sous WIndows et Mac OS, vous trouverez les binaires sur cette page.

Pour configurer unison, créons un répertoire qui lui sera dédié dans votre répertoire utilisateur, sur votre propre machine :

mkdir ~/.unison

root = /home/<utilisateur local>/
root = ssh://<utilisateur distant>@exemple.fr//home/<utilisateur distant>/
times = true
auto = true
batch = true
silent = true

La première ligne indique la racine des fichiers locaux à copier, ici, votre répertoire utilisateur.

La seconde ligne indique la connexion ssh à utiliser pour synchroniser les fichiers avec le répertoire distant : ici, le home de l’utilisateur distant.

Ensuite, nous préservons les dates et heures affectées aux fichiers (time), et nous voulons une procédure la plus silencieuse possible.

La première fois que vous exécuterez unison, l’application vous posera des questions relatives à la synchronisation. Contentez-vous de valider avec la touche Entrée de votre clavier.

Mais avant d’exécuter unison pour la première fois, il faut créer une clé d’accès SSH. Toujours sur votre propre machine :

ssh-keygen -t rsa -f ~/.ssh/id_rsa_<nom>

Vous remplacerez <nom> par une valeur vous permettant de savoir qu’il s’agit de la clé permettant la synchronisation de vos fichiers avec le serveur. L’idée, c’est de la différencier d’autres clés que vous auriez pu créer avant.

Une fois créée, envoyez-la au serveur :

ssh-copy-id -i ~/.ssh/id_rsa_<nom> <utilisateur distant>@exemple.fr

De même, remplacez les valeurs entre chevrons pour qu’elles correspondent à votre situation.

Dernière étape avant de lancer la première synchronisation, ouvrir le port 22 sur le serveur. Reprenez notre script de mise en place du firewall sur le serveur :

nano /scripts/firewall

Entre les lignes :

##### Configuration personnalisée #####

Et :

##### Fin : Configuration personnalisée #####

Rajoutez la ligne suivante :

${IPT} -A SERVICES -p tcp --dport 22 -j ACCEPT

N’oubliez pas de relancer le script :

/scripts/firewall

Bien qu’en début de script nous spécifions l’adresse IP d’une machine toujours autorisée à se connecter, nous ne prévoyons pas que d’autres machines puissent accéder au port 22 (le port utilisé par SSH).

Vu que, dans le cas de l’utilisation d’un smartphone par exemple, on ne peut pas prévoir l’adresse IP du terminal (parce qu’on peut se connecter depuis une borne wifi inconnue), nous devons ouvrir le port 22 de manière systématique.

On peut enfin lancer la première synchronisation, qui va se borner à copier vos fichiers locaux sur le serveur distant. Sur votre machine, lancez simplement :

unison

Et patientez.

Le fichier default.prf que nous venons de créer est considéré par unison comme étant un profil. On peut créer autant de profils que nécessaire. Par exemple, nous avons créé un espace public sur le serveur, dont nous nous servirons plus tard pour stocker des photos et les gérer avec une galerie. Nous verrons alors comment configurer unison pour que cette galerie soit synchronisée avec un répertoire local sous un autre profil.

Pour le moment, il nous reste encore à automatiser la synchronisation de nos documents personnels.

Automatisation

Le problème avec unison (en console sous GNU/Linux), c’est que lors d’une synchronisation, l’application ne vérifie pas si une instance de l’application est déjà en route. Autrement dit, plusieurs instances de unison peuvent tourner en même temps, ce qui peut poser problème lors de longues copies. Pour éviter cela, nous allons devoir créer un script qui se charge de cette vérification. Ce script sera créé sur votre machine avec le super-utilisateur.

En tant que root, créez le script en question :

mkdir /scripts
nano /scripts/unison-launcher

#!/bin/bash

who=`whoami`
mypid=$$
mydir=`dirname $0`
home="/home/$who"
pidfile="$home/unison.pid"

if [ -f "$pidfile" ]
then
        oldpid=`cat "$pidfile"`
        oldpidexists=`ps -p $oldpid | grep -v TTY | awk -F " " '{print $1}'`

        if [ "$oldpidexists" != "" ]
        then
                exit
        fi
fi

touch "$pidfile"
echo $mypid > "$pidfile"

if [ "$1" == "" ]
then
        if [ -f "$home/.unison/default.prf" ]
        then
                unison default
        else
                echo "Le profil par défaut est introuvable ($home/.unison/default.prf)"
        fi
else
        if [ -f "$home/.unison/$1.prf" ]
        then
                unison $1
        else
                echo "Le profil $1 est introuvable ($home/.unison/$1.prf)"
        fi
fi

rm "$pidfile"

Attribuez ensuite les droits d’exécution :

chmod +x /scripts/unison-launcher

Ce script est fait pour permettre la synchronisation de comptes différents sur la même machine.

Il ne reste plus qu’à l’intégrer dans la crontab de chaque utilisateur à synchroniser :

crontab -e

*    *    *    *    *    /scripts/unison-launcher

Vous pouvez passer en argument de ce script le nom d’un profil à charger. Nous le verrons dans un prochain article.

Vérification

Maintenant que la première synchronisation a été effectuée, rendez-vous dans Gollem pour vérifier (http://files.exemple.fr). Vous devez retrouver tous vos fichiers, avec les bonnes permissions, et appartenant à l’utilisateur sur votre serveur.

Via Gollem, créez un répertoire de test. Patientez une minute, puis listez les fichiers sur votre propre machine. Le répertoire en question devrait avoir été créé.

Si tout fonctionne, et que vous disposez d’une autre machine sous GNU/Linux, il vous suffit d’y copier le script /script/unison-launcher pour synchroniser les utilisateurs de cette machine (après avoir créer les profils par défaut, évidemment).

Webdav

Webdav va nous permettre de nous synchroniser avec davantage de clients, et notamment les périphériques Android, puisque unison n’existe pas sous Android. Webdav étant géré par Apache, nous évitons deux écueils : installer une application dédiée (donc faire tourner un service de plus), et ouvrir un port réseau supplémentaire.

Installons tout d’abord quelques dépendances et activons-les :

apt-get install libapache2-mod-auth-pam
a2enmod auth_pam dav_fs dav
a2dismod userdir

Nous devons ensuite modifier un peu la configuration de notre hôte virtuel dans Apache.

nano /etc/apache2/sites-available/files.exemple.fr

Rajoutez les deux lignes suivantes dans la configuration de l’hôte virtuel sécurisé (avant </VirtualHost>) :

Include /etc/apache2/mods-available/userdir.load
Include /etc/apache2/mods-available/userdir.conf

Ensuite, on va modifier la configuration du module userdir :

mv /etc/apache2/mods-available/userdir.conf /etc/apache2/mods-available/userdir.conf-orig
nano /etc/apache2/mods-available/userdir.conf

<IfModule mod_userdir.c>
    UserDir /home
    UserDir disabled root

    DAVLockDB /var/lib/apache2/DAVLockDB

    <Directory /home/*/>
        AllowOverride FileInfo AuthConfig Limit
        Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

        DAV On

        AuthPAM_Enabled On
        AuthPAM_FallThrough Off

        AuthUserFile /etc/shadow

        ForceType text/plain
    </Directory>

    Alias /public /var/public-docs

    <Directory /var/public-docs>
        AllowOverride FileInfo AuthConfig Limit
        Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

        DAV On

        AuthPAM_Enabled On
        AuthPAM_FallThrough Off

        AuthUserFile /etc/shadow

        ForceType text/plain
    </Directory>
</IfModule>

On définit ici que le répertoire utilisateur pour Apache est son home, et on créé un accès au répertoire public. Afin d’éviter que n’importe qui puisse voir le répertoire d’un autre utilisateur, il faut créer un fichier .htaccess dans chaque répertoire utilisateur. Ainsi, seul l’utilisateur connecté peut accéder à son propre répertoire.

nano /home/<utilisateur>/.htaccess

AuthPAM_Enabled on
AuthType Basic
AuthName "PAM"

require user <utilisateur>

Remplacez <utilisateur> par le nom d’utilisateur correspondant au répertoire personnel dans lequel vous mettez ce fichier.

Vous pouvez désormais accéder, via un client dav ou votre navigateur, aux adresses suivantes :

• http://exemple.fr/~utilisateur
• http://exemple.fr/public

Synchronisation avec un client Android

Maintenant que webdav est en place, on va pouvoir configurer un client sous Android.

Et pour cela, nous allons installer sur le terminal l’application WebDav File Manager.

Expliquer comment configurer le client sortirait du cadre de cet article déjà bien touffu par ailleurs. La page suivante vous permettra de configurer l’application ainsi que la synchronisation.

Nous verrons, en revanche, dans notre prochain article, comment configurer l’application pour envoyer automatiquement les photos prises avec le terminal vers notre serveur.

Conclusion

Un tel article mérite bien une conclusion particulière. Nous avons maintenant mis en place tout ce qu’un service comme Dropbox peut fournir, et peut être même plus encore (nous le verrons dans les prochains articles). En l’occurrence :

• on peut accéder à nos fichiers depuis un navigateur et via webdav, donc depuis des périphériques nomades
• nos données sont synchronisées donc accessibles depuis n’importe où
• l’accès à nos données se fait seulement via SSH ou SSL, donc les transferts sont sécurisés
• on peut gérer la bande passante allouée à l’accès aux fichiers
• on va pouvoir installer des applications web dédiées à la gestion de certains types de fichiers, de façon plus puissante et plus agréable que tout autre service intégré
• on dispose d’une excellente base pour faire bien d’autres choses avec nos fichiers !

Voilà donc cet article consacré à la mise en place d’une alternative à Dropbox terminé. Il s’agissait là probablement du plus complexe que nous ayons eu à aborder depuis le début de l’installation de notre cloud personnalisé. Il est aussi peu probable que les articles suivants soient aussi long et difficiles à intégrer que celui-ci. Nous avons vu un certain nombre de notions relativement complexes, sans compter les petites modifications à apporter ça et là à des applications existantes (nous l’avons fait pour status.net, nous le faisons ici avec Horde).

Donc, même si vous n’avez pas eu le courage de tout mettre en œuvre, j’espère néanmoins que cet article (et les autres !) vous a intéressé.

Prochainement, nous installerons une application pour partager ses photos, application qui reposera sur le dossier public que nous avons mis en place, et dont la mise à jour sera automatique. Cerise sur le gâteau : quand vous prendrez une photo depuis votre smartphone, celle-ci sera automatiquement envoyée à la galerie et intégrée, exactement comme avec Google et Picasa, sauf que nous n’aurons recours qu’à des Logiciels Libres !

Ensuite, nous renforcerons la sécurité de notre serveur. Nous mettrons en place un système de sécurité préventif, autant que défensif.

L’article d’après sera consacré à la sauvegarde et la restauration de notre serveur.

Enfin, je publierai un dernier article, conclusion globale de tout le chapitre sur l’installation d’un cloud personnel.

Lire la Suite »]]> SMP (pour Share My Pics) est une application que j’ai développé pour proposer une alternative à twitpic. Son objectif est de partager certains fichiers sur les réseaux sociaux, notamment des images (d’où son nom), en évitant de les envoyer sur ces réseaux. Cela permet de rester maître de ses données puisqu’elles ne quittent pas votre serveur.

Encore en développement, sa procédure d’installation peut sembler compliquée : je n’ai pas créé d’installateur, et son téléchargement depuis redmine n’est pas vraiment « user-friendly« . Cependant, elle est suffisamment stable et propose suffisamment de fonctionnalités pour être parfaitement utilisable. C’est également l’occasion pour moi de vous inciter à vous en servir, de sorte à me permettre de l’améliorer. Et si vous souhaitez tester un peu l’application, vous trouverez mon instance en cliquant ici.

Installation des pré-requis

La procédure d’installation de SMP et l’application en elle-même nécessitent quelques paquets :

apt-get install git php-gettext
pear install mail html_tagcloud mdb2 mdb2_driver_mysql

Hôte virtuel

Première chose, comme d’habitude, on s’occupe de l’hôte virtuel dans apache :

nano /etc/apache2/sites-available/smp.exemple.fr

<VirtualHost *:80>
	ServerName smp.exemple.fr
	Redirect / https://smp.exemple.fr/
</VirtualHost>

<VirtualHost *:443>
	ServerName smp.exemple.fr

	DocumentRoot /var/www/exemple.fr/smp/www

	SSLEngine On
	SSLCertificateFile /scripts/certificate_authority/apache/smp.exemple.fr.crt
	SSLCertificateKeyFile /scripts/certificate_authority/apache/smp.exemple.fr.key

        CustomLog /var/www/exemple.fr/smp/log/access.log
        ErrorLog /var/www/exemple.fr/smp/log/error.log
</VirtualHost>

Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe. Créons maintenant les certificats :

/scripts/certificate_authority/make_request apache smp.exemple.fr
/scripts/certificate_authority/sign_request apache smp.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*

On active le site, et on redémarre apache :

a2ensite smp.exemple.fr
/etc/init.d/apache2 restart

Installation de SMP

Vous devez tout d’abord vous créer un compte sur la page suivante. Il s’agit de mon dépôt privé. Une fois votre compte créé et que vous vous êtes connecté, allez dans les paramètres de votre compte (lien Mon compte en haut à droite). Vous verrez un lien Public Keys. Pour pouvoir accéder au dépôt, vous allez renseigner une clé ssh.

Saisissez la commande suivante :

ssh-keygen -t rsa -f id_ingnu

Si vous spécifiez un mot de passe, vous devrez le saisir chaque fois que vous ferez usage de la clé (pour mettre à jour le dépôt ou le télécharger).

Cette commande va créer deux fichiers :

~/.ssh/id_ingnu         Clé privée
~/.ssh/id_ingnu.pub     Clé publique

Affichez le contenu de la clé publique :

cat ~/.ssh/id_ingnu.pub

Copiez cette clé, puis retournez dans redmine, dans l’interface de gestion des clés, puis créez-en une nouvelle, et collez le contenu de votre clé publique réservée à ingnu. Enfin, sauvegardez.

On télécharge SMP et on l’installe :

cd /usr/src
git clone git@ingnu.fr:/smp.git
cp -Rv smp/* /var/www/exemple.fr/smp/www/
cd /var/www/exemple.fr/smp/www
mv settings.dist.php settings.php

On créé ensuite l’utilisateur MySQL dont on va avoir besoin (je ne ré-explique pas la procédure, vous devez maintenant avoir l’habitude ). Nommez-le par exemple SMP. Ensuite, saisissez la commande suivante (en console bien sûr) pour créer la structure de la base de données :

mysql -u root -pVotreMotDePasse SMP < documents/databases/mysql.sql

On peut maintenant éditer la configuration de SMP (vous trouverez tous les détails sur le wiki de SMP).

nano settings.php

Sachez que pour le moment, SMP ne propose aucune interface d’administration : tout se configure le plus simplement du monde depuis le fichier settings.php. Consultez également le wiki pour voir quelles sont les extensions disponibles et comment les configurer.

Lorsque vous aurez terminé la configuration de SMP, attribuez les bons droits au dossier :

chown -R www-data:www-data ./

Premiers pas

Ouvrez votre site (http://smp.exemple.fr), puis créez votre compte utilisateur. Si vous avez activé la confirmation par mail, effectuez-la puis revenez dans SMP.

Une fois connecté, vous pouvez cliquer sur la première étape pour afficher et modifier les paramètres de votre compte, et surtout pour lier vos comptes de réseaux sociaux. La procédure est extrêmement simple (une fois les clés obtenues de ces réseaux sociaux), et est documentée dans le wiki.

Vous noterez qu’à tout moment, vous pouvez délier un compte de réseau social. Par exemple, si vous avez lié votre compte facebook et votre compte twitter, et si vous voulez partager un fichier uniquement avec vos contacts facebook, il vous suffit de délier le compte twitter. Par la suite, vous pourrez tout aussi facilement lier à nouveau ce compte.

L’envoi de fichier est lui aussi extrêmement simple : on lui donne éventuellement un titre, on lui affecte éventuellement des mots-clés, on spécifie le fichier, et on envoi. Une fois envoyé, le lien direct vers le fichier vous sera présenté.

Vous pourrez alors consulter la timeline publique, où votre premier fichier devrait se trouver.

Développement de SMP

SMP est en développement actif : de nouvelles fonctionnalités et des corrections de bugs sont régulièrement publiées (du moins, j’essaye). Consultez l’état des demandes en cours pour voir où j’en suis.

Lorsqu’une mise à jour est publiée, vous voudrez peut-être également mettre à jour votre propre instance de SMP. Rien de plus simple :

cd /usr/src/smp
git pull
cp -Rv smp/* /var/www/exemple.fr/smp/www/

Si vous souhaitez contribuer à SMP, plusieurs options s’offrent à vous : forker le projet, ou proposer vos commits directement dans la branche master. Si ma phrase est du chinois pour vous, vous devriez jeter un oeil à la documentation de git (officielle et non-officielle), qui vous expliquera bien mieux que moi les tenants et aboutissants du développement de groupe

Conclusion

J’espère que cette application vous donnera satisfaction. En début d’année, je m’étais fixé pour objectif de réaliser et publier une application sous licence libre. C’est chose faite avec SMP, et j’ai bon espoir qu’elle trouvera son public.

En attendant, vous disposez d’une solution libre, équivalente à twitpic, vous permettant de partager vos fichiers sur vos réseaux sociaux. N’hésitez pas à me faire part de vos appréciations !