Une alternative à Dropbox

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/*

Warning : Common Name

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

Important : /var/www/exemple.fr/files/www

/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

Important : /var/log/auth.log

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 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.

Important : notre série consacrée à la mise en place d’un cloud personnel

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.

Notice : default.prf

.unison

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 ) :

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 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.

Échanger autour de ce texte

Si vous souhaitez réagir publiquement, un fil dédié vous attend.

Ouvrir le fil de discussion