--- comments_url: https://com.richard-dern.fr/post/520 date: '2012-02-12 20:36:00' dossier: - Créer son propre Cloud links: - lang: fr name: Archive url: http://ingnu.fr/2012/02/12/une-alternative-a-dropbox/ tags: - Apache - Gollem - Horde - Unison - WebDAV title: Une alternative à Dropbox weather: humidity: 56 illuminance: 0.0 precipitations: false pressure: 1025.6 source: - open-meteo temperature: -7.7 wind_direction: 103 wind_speed: 6.3 weight: 10 --- 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](http://sparkleshare.org/) ou [OwnCloud](http://owncloud.org/) (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](http://www.truecrypt.org/legal/license) (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](http://www.horde.org/apps/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](http://ingnu.fr/2012/02/07/kronolith-une-alternative-a-google-calendar/). 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 : ```bash mkdir -p /var/www/exemple.fr/files/{log,www} nano /etc/apache2/sites-available/files.exemple.fr ``` ```text ServerName files.exemple.fr Redirect / https://files.exemple.fr/ 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 ``` 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 : ```bash /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 : ```bash a2ensite files.exemple.fr /etc/init.d/apache2 restart ``` On installe ensuite notre instance de PEAR. ```bash 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 : ```bash /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_ ```bash /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 : ```bash /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](http://ingnu.fr/2012/02/07/installation-dun-serveur-http-https/) 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 : ```bash pecl install pam ``` Et modifier Horde : ```bash nano /var/www/exemple.fr/files/pear/php/Horde/Auth/Pam.php ``` Changez la ligne 40 : ```php if (!Horde_Util::extensionExists('pam')) { ``` Pour inclure l'extension _pam_auth_ : ```php 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 : ```bash 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 : ```bash adduser www-data shadow ``` Puis redémarrez Apache : ```bash /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](http://ingnu.fr/2012/02/07/kronolith-une-alternative-a-google-calendar/)). 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 : ```bash /var/www/exemple.fr/files/pear/pear -c /var/www/exemple.fr/files/pear.conf install -a -B horde/gollem ``` Puis corrigez les droits : ```bash 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. ```bash cd /var/www/exemple.fr/files/www/gollem/config mv backends.php backends.php-orig nano backends.php ``` ```php 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 : ```bash 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. ```bash nano /var/www/exemple.fr/files/www/config/conf.php ``` Modifiez la ligne : ```php $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](http://www.cis.upenn.edu/~bcpierce/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](http://jaqque.sbih.org/kplug/apt-pinning.html)), vous pouvez télécharger le paquet directement depuis [cette page](http://packages.debian.org/wheezy/unison). Si c'est la voie que vous avez choisi, vous utiliserez _dpkg_ : ```bash dpkg -i unison_2.40.63-2_amd64.deb ``` Sinon, _apt-get_ : ```bash apt-get -t testing install unison ``` Sous WIndows et Mac OS, vous trouverez les binaires sur [cette page](http://alan.petitepomme.net/unison/index.html). Pour configurer unison, créons un répertoire qui lui sera dédié dans votre répertoire utilisateur, sur votre propre machine : ```bash mkdir ~/.unison ``` ```text root = /home// root = ssh://@exemple.fr//home// 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 : ```bash ssh-keygen -t rsa -f ~/.ssh/id_rsa_ ``` 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 : ```bash ssh-copy-id -i ~/.ssh/id_rsa_ @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](http://ingnu.fr/2012/02/05/creer-son-propre-cloud-introduction/) sur le serveur : ```bash nano /scripts/firewall ``` Entre les lignes : ```text ##### Configuration personnalisée ##### ``` Et : ```text ##### Fin : Configuration personnalisée ##### ``` Rajoutez la ligne suivante : ```text ${IPT} -A SERVICES -p tcp --dport 22 -j ACCEPT ``` N'oubliez pas de relancer le script : ```bash /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](http://ingnu.fr/category/creer-son-propre-cloud/) 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 : ```bash 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 : ```bash mkdir /scripts nano /scripts/unison-launcher ``` ```bash #!/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 : ```bash 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 : ```bash crontab -e ``` ```text * * * * * /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 : ```bash 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. ```bash nano /etc/apache2/sites-available/files.exemple.fr ``` Rajoutez les deux lignes suivantes dans la configuration de l'hôte virtuel sécurisé (avant ) : ```text Include /etc/apache2/mods-available/userdir.load Include /etc/apache2/mods-available/userdir.conf ``` Ensuite, on va modifier la configuration du module userdir : ```bash mv /etc/apache2/mods-available/userdir.conf /etc/apache2/mods-available/userdir.conf-orig nano /etc/apache2/mods-available/userdir.conf ``` ```text UserDir /home UserDir disabled root DAVLockDB /var/lib/apache2/DAVLockDB AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec DAV On AuthPAM_Enabled On AuthPAM_FallThrough Off AuthUserFile /etc/shadow ForceType text/plain Alias /public /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 ``` 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. ```bash nano /home//.htaccess ``` ```text AuthPAM_Enabled on AuthType Basic AuthName "PAM" require user ``` 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](https://market.android.com/details?id=jp.ddo.shigadroid.webdavfilemanager). Expliquer comment configurer le client sortirait du cadre de cet article déjà bien touffu par ailleurs. [La page suivante](http://shigadroid.web.fc2.com/en/) 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~~](http://ingnu.fr/2012/02/08/son-propre-reseau-social-avec-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.