Quelles alternatives libres à Dropbox ?

53
23
avr.
2014
Cloud

La société Dropbox a accueilli une nouvelle personne à son conseil d'administration : Condoleezza Rice, conseillère à la sécurité nationale de l'ère Bush et connue pour avoir approuvé des écoutes illégales. Confier ses données à une entreprise requiert une grande confiance et Dropbox vient de perdre la confiance de beaucoup d'utilisateurs. Dropbox s'est empressé d'affirmer que sa stratégie de protection des données reste inchangée.

Dropbox

Si comme beaucoup vous décidez d'abandonner Dropbox, pourquoi ne pas passer à un logiciel libre pour gérer et stocker la mise à disposition de fichiers ? De nombreuses solutions existent, avec serveur ou en peer-to-peer.

Avec serveur

Avec ces solutions, l'idéal est d'avoir son propre serveur. Pour ceux qui n'ont pas l'inclination de maintenir un serveur, des offres d'hébergement payantes et gratuites sont souvent disponibles. Choisissez un hébergeur en lequel vous avez confiance, dans un pays respectueux de vos libertés. Une fois que le serveur est en place, il suffit de s'y connecter avec le logiciel client.

  • Owncloud, qui requiert un serveur OwnCloud. Nombreuses offres d'hébergements à travers toute l'Europe. Beaucoup de fonctionnalités annexes, ce qui peut être un inconvénient. GNU-AGPLv3 pour le serveur, GNU-GPLv3 pour Linux/Windows/Mac/Android, licence MIT pour iOS.
  • Seafile, qui requiert un serveur dédié. GNU-GPLv3. Linux/Windows/Mac/Android/iOS.
  • Pydio (anciennement Ajaxplorer), qui est écrit en Javascript et PHP. Nécessite un serveur Web quelconque avec PHP5 dont les extensions MCrypt et GD. Simple à mettre en place. C'est un projet qui semble dynamique, plutôt ergonomique. GNU-AGPL. Linux/Windows/Mac.
  • SparkleShare, qui requiert un serveur Git. Idéal avec de petits fichiers, notamment pour les grandes équipes qui veulent un historique complet. GNU-GPLv3. Linux/Mac/Windows.
  • git-annex assistant, aussi basé aussi sur Git mais mieux équipé pour les gros fichiers. GNU-GPLv3. Linux/Windows/Mac/Android. Ne nécessite pas forcément de serveur central.
  • Syncany, qui requiert un serveur FTP ou WebDAV. GNU-GPLv2. Linux/Windows/Mac.
  • CmisSync, qui requiert un serveur de GED. Adapté aux entreprises qui disposent déjà d'un serveur Alfresco, Nuxeo, SharePoint ou autre. GNU-GPLv3. Linux/Windows/Mac.
  • Unison, qui nécessite une configuration en étoile, avec un "hub" au centre. Unison a l'avantage d'exister depuis longtemps, mais il souffre d'une certaine vétusté, il est difficile à mettre en place pour un utilisateur lambda et son code source en OCaml n'attire pas foule de développeurs. GNU-GPLv3. Linux/Windows/Mac.
  • NdM : On nous signale Cozy dans les commentaires. En plus du gestionnaire de fichiers, ce cloud perso s'accompagne d'autres applications comme un carnet de contacts, un calendrier, un lecteur de flux RSS…

En peer-to-peer

Si votre smartphone est allumé la plupart du temps, vous n'avez pas vraiment besoin d'un serveur. Le logiciel non-libre BitTorrent Sync l'a compris et connait actuellement un succès phénoménal qui lui vaut le surnom de Dropbox-killer. Des solutions Open Source existent aussi, pour l'instant loin de rivaliser (en particulier, pas d'application pour smartphone).

Le principe est de créer un "secret" sur l'appareil contient le répertoire à partager, puis renseigner ce secret sur chaque appareil à connecter.

  • Tahoe-LAFS est volontairement axé sur la sécurité des données, non seulement du point de vue de la disponibilité (en faisant en sorte que vos données soient suffisamment réparties), mais également du point de vue de la confidentialité (tout est chiffré, seules les personnes qui obtiennent un lien direct ont accès aux données en clair). L'organisation d'un groupe de pairs se fait typiquement sur les relations de confiance entre plusieurs humains qui veulent collaborer ensemble. GNU-GPLv2. Linux.
  • syncthing dont le but affiché est d'être un équivalent Open Source de BitTorrent Sync, codé en Go. Comme BitTorrent Sync, le client est une interface web locale. Licence MIT. Linux/Windows/Mac.
  • ClearSkies, la même chose en C++. GNU-LGPLv3. Seulement au stade de prototype, client basique en Python.
  • Hive2Hive qui se concentre pour l'instant sur sa bibliothèque. Licence MIT. Pas de client.
  • # Et Cozy !

    Posté par (page perso) . Évalué à 6. Dernière modification le 23/04/14 à 16:00.

    Et n'oubliez pas le petit français Cozy ! http://cozy.io. En plus du gestionnaire de fichiers, ce cloud perso s'accompagne d'autres applications comme un carnet de contacts, un calendrier, un lecteur de flux RSS…

    • [^] # Re: Et Cozy !

      Posté par (page perso) . Évalué à 4. Dernière modification le 23/04/14 à 16:01.

      http://cozy.io/ NdM: corrigé dans le commentaire précédent

    • [^] # Re: Et Cozy !

      Posté par (page perso) . Évalué à 4.

      Le site web de Cozy ne parle pas de synchronisation de fichiers. Dans la démo je viens une app appelée "files", mais pas de client desktop à l'horizon. Est-ce une fonctionnalité cachée ? Ou Cozy est juste un serveur, sur lequel je peux installer un des outils mentionnées dans la dépêche ci-dessus ?

      • [^] # Re: Et Cozy !

        Posté par . Évalué à 3. Dernière modification le 24/04/14 à 12:10.

        visiblement, le client desktop devait arriver pour février, mais je n'ai pas trouver non plus d'infos sur une quelconque release :
        https://groups.google.com/forum/?fromgroups#!searchin/cozy-cloud/cozy$20desktop$20client/cozy-cloud/wx6PvJbb9t0/r3XQV21IC9YJ

        Mais il semble que tu puisses le configurer avec n'importe quel client qui supporte webdav

        • [^] # Re: Et Cozy !

          Posté par (page perso) . Évalué à 3. Dernière modification le 24/04/14 à 18:35.

          Effectivement les choses ont pris pas mal de retard. On devait le faire pour un client mais il nous a demandé pas mal de développements spécifiques. Du coup la version que nous avons n'est pas publiable. Le projet se terminant on a repris les choses du côté des clients Linux/MacOSX et Android.

          • La version Android est déjà testable. Voir les infos ici.
          • Pour le client Linux/OSX, le dépôt est dispo ici. Mais c'est encore instable et lent.
  • # chiffrement

    Posté par . Évalué à 10.

    Pour ceux qui sont tenté par « l'externalisation des données », on peut aussi conseiller très très fortement le chiffrement des données, notamment en entreprise. Des conteneurs TrueCrypt, GPG ou autres sont à recommander.

    • [^] # Re: chiffrement

      Posté par . Évalué à 6.

      Encfs pour moi!

    • [^] # Re: chiffrement

      Posté par (page perso) . Évalué à 2.

      Ou pour être plus efficace, d'utiliser une solution qui crypte sur le client directement donc seafile ou sparkleshare (de façon native) ou git-annex avec une remote de type gcrypt (http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/). Syncany fait ça aussi, mais à mon avis, ce n'est pas assez stable. En outre le choix de ne pas utiliser de serveur rend le design fragile (en terme de système réparti c'est un vrai challenge de réussir une exclusion avec un stockage idiot comme unique support).

  • # Owncloud, Seafile et Tahoe-LAFS

    Posté par . Évalué à 10.

    Personnellement je suis utilisateur de Dropbox et j'avais cerné mes besoins ainsi :

    • Partage de fichiers (surtout audio/vidéos) en lecture ou lecture-écriture
    • Possibilité d'avoir un lien public (pas besoin de s'enregistrer pour récupérer un fichier)
    • Possibilité d'accès via le navigateur pour naviguer dans le répertoire partagé pour visionner les photos/vidéos
    • Stockage en ligne avec synchronisation avec ma machine locale (Debian)

    Le cas d'utilisation typique c'est la fête de famille où tout le monde souhaite s'échanger et regarder les photos.

    Voici mon léger retour d'expérience sur quelques solutions:

    • Tahoe-LAFS: la cible est plus le stockage distribué et sécurisé que le partage facile.
    • Owncloud: simple pour l'utilisateur mais en tant qu'administrateur du serveur, j'ai testé les versions majeures 3, 4 et 5 à leur sortie et j'ai eu pleins de petits bogues à chaque fois censés être corrigés dans la version majeure suivante (j'ai remonté les bogues et participé à 2-3 patches).
    • Seafile: installation du serveur vraiment complexe (j'ai tenté postgresql+nginx). Je n'ai pas réussi à aller jusqu'au bout (mais mes compétences d'administrateur sont pas au top).

    Vraiment il faut reconnaître à Dropbox d'avoir réussi à rendre très accessible une technologie pas vraiment évidente. J'aide dans la mesure de mes moyens, mais les solutions libres ont du chemin à faire pour le rattraper !

    • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

      Posté par (page perso) . Évalué à 3.

      simple pour l'utilisateur mais en tant qu'administrateur du serveur, […] installation du serveur vraiment complexe […]
      Vraiment il faut reconnaître à Dropbox d'avoir réussi à rendre très accessible une technologie pas vraiment évidente.

      Si le problème comparé à dropbox est la gestion du serveur, dans ce cas il faut opté pour les offre d'hébergement de owncloud qui gerre le serveur pour toi. Il fallait suivre le liens dans la dépêche vers http://owncloud.org/providers/

      Là encore on remets ses données dans les main d'une tierce entreprise. Mais au moins les logiciels (client, serveur) sont libres et les protocols sont ouverts.

      • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

        Posté par . Évalué à 5.

        Administrer Owncloud était relativement simple (la complexité c'était avec Seafile). C'est les bogues rencontrés (en tant qu'administrateur ou utilisateur) qui m'ont plutôt gêné.

        [mavie]

        J'ai rencontré pas mal de soucis mais d'autres avaient déjà remonté l'erreur. Ayant testé la version 3, 4 et 5, j'avais l'impression d'une priorité donnée aux fonctionnalités et à l'interface plutôt qu'à la stabilité. Il y a eu d'ailleurs un message sur la liste de diffusion qui m'avait marqué : Regarding quality. J'ai laissé de côté (faute de temps) après avoir vu plusieurs messages de suite de personnes ayant de gros problème de mise à jour entre la version 4 et la version 5 :
        Upgraded to Owncloud 5. Here come the conflict files again
        upgrade from 4.5 to 5.0 lost all files
        [/mavie]

        Après que les choses soient claires : c'est du logiciel libre et c'est déjà très bien qu'il existe et qu'il évolue. Je crois suffisamment au projet pour y avoir investi un peu de temps et je pense peut être y retourner un jour.

        • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

          Posté par (page perso) . Évalué à 6.

          J'ai par exemple tenté l'aventure avec Postgresql (c'était peut-être ma faute d'avoir choisi autre chose que le standard Mysql)

          Oui, Owncloud supporte officiellement pgsql mais en fait, tu te retrouve avec pleins de bug à chaque migration. En fait, il ne tourne bien qu'avec Mysql.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

            Posté par . Évalué à 0.

            Je comprends pas pourquoi MySQL semble si souvent privilégié à PostgreSQL dans divers projets alors que la supériorité du dernier n'est plus à démontrer…

            • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

              Posté par (page perso) . Évalué à 5.

              Parce que Mysql est partout. Trouver un hébergement avec MySQL ne pose pas de problème, en trouver avec un pgsql, ça devient plus compliqué. Et comme c'est comme ça depuis quelques temps, ça fait effet boule de neige, les hébergeurs ne proposent plus que MySQL parce que les softs le prennent en charge, voire ne gère que ça. Et les soft le prennent en charge, voire ne gèrent que ça parce que les hébergeurs ne proposent que ça.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

                Posté par . Évalué à 3.

                Ça m'a l'aire d'être de moins en moins le cas. On a de plus en plus d'hébergement qui s'éloignent du poussiéreux LAMP. Free propose postgresql, les clouds proposent des solutions de stockage NoSQL la majorité du temps et les solutions du type serveurs dédiés sont de plus en plus démocratiser.

                Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

                  Posté par (page perso) . Évalué à 3.

                  J'ai plus l'impression que les gens s'éloignent des hébergeurs pour se tourner vers Facebook/Dropbox/Youtube/… Et donc, en proportion, on voit plus de truc pour power user qui étaient là avant quand même, juste moins utilisé en proportion.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

                    Posté par . Évalué à 4.

                    Les machins clouds sont relativement récents (GAE, EC2, etc). Ce qu'il faut c'est voir qui va installer ces solutions et sur quoi ils vont le faire. Aujourd'hui tu as largement plus de choix qu'il y a 5 ans pour faire autre chose que du LAMP. Les hébergeurs de contenus n'ont rien avoir avec ce dont on parle.

                    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

      Posté par . Évalué à 3.

      Personnellement j'avais trouvé ownCloud assez lent (en web) et peu fiable en synchronisation mais avec la version 6 ça marche vraiment très bien. Actuellement j'ai un vps OVH classic 1 sur une Debian avec Owncloud 6 et Ampache, ça tourne au poil pour de la synchro fichier (2 PC Linux + 1 Android) et de la synchro calendrier/contact sur Evolution/Android. Je me suis débarrassé de la grosse partie Google sur mon Android, j'ai juste laissé le compte pour Google Play (seul synchro active).

      de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité

      • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

        Posté par (page perso) . Évalué à 1.

        Actuellement j'ai un vps OVH classic 1 sur une Debian avec Owncloud 6 et Ampache

        et donc, tu vas aussi évoluer concernant ampache ?
        cf. http://linuxfr.org/news/ampache-doped-ampache-part-en-fourchette

      • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

        Posté par . Évalué à 1.

        j'ai juste laissé le compte pour Google Play (seul synchro active).

        Tu pourrais aussi t'en débarrasser, il y a script dispo qui permet de télécharger les APK, fait par un gars passant aussi par ici, j'ai oublié le nom, désolé.

        Il te faudra toujours un compte google mais tu pourrais en faire un non-officiel.

        • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

          Posté par . Évalué à 1.

          Si sur son téléphone il n'utilise un compte Google que pour Play, il peut tout aussi bien en utiliser un "non officiel" directement.

          Ou alors je n'ai pas compris ce que tu veux dire.

        • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

          Posté par . Évalué à 1.

          Je ne comprend pas l'intérêt d'utiliser cette application si je dois utiliser un autre compte Google ? Ou alors il y a quelque chose qui m'échappe :)

          Bon de toute façon j'ai commencé à tester ownCloud et autre (caldav, carddav) pour pouvoir switcher d'içi quelques temps de Android vers jolla ;)

          de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité

          • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

            Posté par . Évalué à 0.

            ne pas avoir l'identifiant de ton tel associé à ce compte, vu que ce dernier est deja associé à ton compte original.
            bref. limiter/stopper l'empreinte que tu laisses chez google

            • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

              Posté par . Évalué à 0.

              En fait je n'ai plus rien sur mon compte Google/Gmail et autre, il reste juste le spam :)

              de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité

          • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

            Posté par (page perso) . Évalué à 1.

            Je ne comprend pas l'intérêt d'utiliser cette application si je dois utiliser un autre compte Google ?

            Moi je vois un intérêt énorme, c'est de ne pas avoir à installer l'application Google Play elle-même.

            Le principal défi pour le futur d'Android en tant qu'écosystème libre est de réussir à éviter Google Play Services, la grosse boite noire propriétaire (et non-redistribuable) qui malheureusement prend de plus en plus de place dans Android, sous la pression de Google. Je vois deux stratégies possibles:

        • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

          Posté par (page perso) . Évalué à 2.

          Malheureusement elle ne fonctionne pas pour télécharger les APK payants (même si on a renseigné son compte google perso au lieu de celui par défaut, et qu'on a acheté l'app via le store web). Du moins quand j'ai essayé en décembre.

    • [^] # Re: Owncloud, Seafile et Tahoe-LAFS

      Posté par (page perso) . Évalué à 3. Dernière modification le 24/04/14 à 15:11.

      Tahoe-LAFS: la cible est plus le stockage distribué et sécurisé que le partage facile.

      Je pense que c'est vrai, mais en plus d’être distribué et chiffré c'est quand même super simple pour le partage.

      Par défaut tout ce que tu mets dans Tahoe-LAFS est immuable; lorsque tu donnes la référence d'un fichier a quelqu'un, tu lui donnes une identité immuable. Il peut uploader une autre version mais elle aura une autre identité et il faudra alors convaincre les autres que sa version est la bonne.

      Les dossiers sont (en général) mutables, c'est-a-dire que tu peux modifier leur contenu et garder la même identité. Cette identité mutable est basée sur une bête paire de clés asymétriques (RSA pour le moment). Lorsque tu as créé le dossier tu as 2 identités: une qui contient la clé privée et une qui ne la contient pas. Tu peux choisir de donner la première, et tout ceux qui ont cette référence pourront modifier la valeur pointée par cette référence (puisqu'ils ont la clé privée), ou tu peux donner la deuxième, que les autres pourront seulement lire.

      Et tout ça se fait de manière transparente pour l'utilisateur: tout ce qu'il voit c'est une URI qui peut pointer sur n'importe lequel des nœuds qui servent du HTTP.

      Ah et en plus de ça, pour l'installation, tu galères peut-être un peu (ou pas) pour installer les dépendances python, mais après ça marche nickel.

  • # Quid de la robustesse de ces solutions ?

    Posté par . Évalué à 7.

    Mon modeste point de vue est assez peu engageant :
    - Dropbox est fiable, pas super accessible (bloqué par pas mal de proxies) et douteux du point de vue de la confidentialité
    - Digiposte est fiable, top sur la confidentialité, mais très peu accessible (nécessité de passer par le site web ou une appli smartphone)
    - Owncloud et compagnie ont la réputation (sur Linuxfr) d'être peu fiables (fichiers perdus ou non synchronisés), assez accessibles, et diversement sécurisés (ça dépend beaucoup du professionnalisme de l'administrateur du serveur)

    Existe-t-il un comparatif de ces outils sur la base de mesures de leur fiabilité, de leur disponibilité/accessibilité et de leur confidentialité en conditions réelles ?

    BeOS le faisait il y a 15 ans !

  • # Camlistore

    Posté par (page perso) . Évalué à 7.

    Je ne sais pas si le développement est actif ou pas, mais il y a aussi http://camlistore.org/

    • [^] # Re: Camlistore

      Posté par . Évalué à 2.

      Le développement est de plus en plus actif oui.
      Pour l'instant c'est surtout de la ligne de commande pour Linux, Windows et Mac OSX et des clients Android et iOS sont disponibles dans les sources du projet.

  • # syncthing

    Posté par (page perso) . Évalué à 5.

    Je découvre Syncthing et je suis en train de tester, c'est génial!
    Excellente dépêche, merci.

    wind0w$ suxX, GNU/Linux roxX!

    • [^] # Re: syncthing

      Posté par . Évalué à 6.

      C'est pas mal, et ça ressemble pas mal à Teapotnet (qui ne bouge plus beaucoup?), mais avec un gros bémol : Teapotnet était capable de mettre en relation N*N des machines cachées chacune derrière un NAT, dès lors que l'une d'entre elles était accessible par tout le monde. Ici, deux machines ne peuvent se parler que si au moins une d'entre elles est accessible (i.e. via PortForward ou uPNP). Dommage, même si ça semble évoluer vite.

      • [^] # Re: syncthing

        Posté par (page perso) . Évalué à 2.

        Assez déçu après 2 jours de test je ne suis pas convaincu.

        Je vais attendre que ça évolue, trop d'erreurs de synchronisation comme avec BitTorrent Sync.
        Les liens symboliques n'ont pas l'air d'être pris en compte d'ailleurs.
        La doc est trop succincte et pas moyen de savoir ce qui se passe quand des fichiers qui devraient être synchronisés ne le sont pas.

        Dommage, les dossiers ~/Sync avaient l'air de bien fonctionner mais quand j'ai voulu ajouter un dossier maître sur une machine en read-only et à tenter de le synchroniser avec un autre sur une seconde machine celle-ci ne voyait pas la moitié des fichiers ou dossiers à synchroniser.

        Je vais garder ma méthode à base de rsync qui a l'avantage d'être très fiable.

        wind0w$ suxX, GNU/Linux roxX!

        • [^] # Re: syncthing

          Posté par . Évalué à 2.

          J'ai regardé un peu le protocole et ça m'a l'air assez clean. Tu penses que ça vient de l'implémentation ? D'après le bug tracker, il y a pas mal de problèmes.

          • [^] # Re: syncthing

            Posté par (page perso) . Évalué à 1.

            Je ne sais pas d'où ça vient, je ne connais pas le Go.
            La seule chose que je peux dire c'est qu'à l'usage ce n'est pas fiable pour le moment.
            Beaucoup de bugs et beaucoup ont été corrigés.
            J'espère qu'une prochaine version sera utilisable, ils en sont encore à une v0.8.1.

            wind0w$ suxX, GNU/Linux roxX!

      • [^] # Re: syncthing

        Posté par . Évalué à 1.

        Pour info, les devs de Teapotnet bossent sur une mise à jour majeure (en particulier, je crois qu'ils réécrivent une grosse partie du système de chiffrement). Voir pour des précisions la branche crypto du git :
        https://github.com/paullouisageneau/Teapotnet

  • # Seafile

    Posté par (page perso) . Évalué à 6.

    J'utilise seafile depuis plus d'un an, et il marche farpaitement bien.

    L'installation est vraiment aisée (mais pas très standard).
    Et le projet semble bien vivant, plusieurs versions sont sorties dans l'année; sans aucun souci pour l'upgrade, à chaque fois.

    Juste avant j'avais utilisé owncloud, et eu des soucis en masse avec la synchro. Même s'il paraît que "ça va mieux maintenant", j'ai été refroidi.

    Du coup, bah, je recommande Seafile.

    • [^] # Re: Seafile

      Posté par (page perso) . Évalué à 2.

      Il a l'air efficace et fiable, j'ai hésité à me lancer dans sa mise en place chez moi. Finalement je ne l'ai pas fait parce qu'il n'est pas directement compatible avec FreeBSD, et je ne me sentais pas trop de m'amuser avec l'émulation de Gnu/Linux pour un outil manipulant mes données.

      Opera le fait depuis 10 ans.

    • [^] # Re: Seafile

      Posté par . Évalué à 1.

      De mémoire j'avais testé Seafile en partant de ce guide : Deploying Seafile with nginx and MySQL on Debian Wheezy
      Et j'avais adapté à l'aide de ces deux pages :

      J'avais trouvé à l'époque toute la procédure vraiment très compliquée et qu'il était facile de faire des erreurs :
      Seafile + Debian Squeeze + MySQL + Apache + non-root domain

      Je n'ai vu que des avis positifs sur Seafile, donc je vais peut-être me retrousser les manches et tenter de nouveau l'aventure !

    • [^] # Re: Seafile

      Posté par (page perso) . Évalué à 3.

      J'ai installé Seafile, il y a deux mois suite à des avis positifs sur Linuxfr et que du bonheur. Une dizaine de personnes sous WIndows et Linux qui synchronisent en permanence et aucun soucis, niveau de service idem à Ubuntu One.

    • [^] # Re: Seafile

      Posté par . Évalué à 3.

      Idem pour moi, Seafile sur un raspberry cela marche du tonnerre!

      • [^] # Re: Seafile

        Posté par . Évalué à 2.

        Idem, je n'ai que d'excellents retours à faire concernant Seafile (nginx+mariadb), je viens d'ailleurs tout juste de mettre à jour mon serveur avec la version 3.0 sortie hier. Simple, efficace, zéro problème. Il manque juste l'auto-upload des photos depuis un mobile Android, point qui a malheureusement été décalé dans la roadmap à la v4.

        Je suis parti de owncloud qui semblait initialement répondre à mes besoins mais que je trouvais lent, lourd à administrer, buggé et ce quel que soit les versions. (stable, nightly build, bêta en version 5 et 6)

        Je n'ai que de supers retours avec les diverses personnes (GNU/linux et windows) qui l'utilisent. Bref, au top pour mes besoins.

        • [^] # Re: Seafile

          Posté par . Évalué à 2.

          Damned c'est vraiment un concert d'éloges pour Seafile, il faut que j'essaye de nouveau.

          Je suis vraiment le seul à avoir galéré pour l'installation du serveur ?
          C'est mon égo qui en prend un coup… ;-)

          • [^] # Re: Seafile

            Posté par . Évalué à 1.

            Mouai..enfin là, après trois heures à patauger, je renonce, c'est déjà super pas évident à configurer sans SSL, mais alors si en plus je tente de rajouter du chiffrement pour l'accès web, c'est juste la misère ! Dommage, ça à l'air top comme projet, mais c'est carrément trop le bronx à mettre en oeuvre pour mes modestes compétences….et j'ose même pas imaginer les upgrades :-(

    • [^] # Re: Seafile

      Posté par (page perso) . Évalué à 2.

      Quand j'installe un service web chez moi, j'aime bien que l'authentification soit gérée par le serveur web (apache ou nginx) et non par l'application.
      Ça me permet d'utiliser ce que je veux pour l'authentification, en évitant les bêtes mots de passe.
      est-ce faisable pour seafile ?

      J'ai l'impression que oui, vu que ça me semble basé sur Django, mais j'aurais aimé être sûr :)

      • [^] # Re: Seafile

        Posté par . Évalué à 3.

        J'utilise nginx devant seafile et j'ai une authentification HTTP en SSL géré par nginx.
        Donc oui c'est possible et tout est bien expliqué dans le wiki de Seafile vraiment bien fait.

  • # Git-annex a-t-il vraiment besoin d'un serveur ?

    Posté par . Évalué à 4.

    Je ne pense pas qu'on puisse dire que Git-annex a vraiment besoin d'un serveur pour faire de l'échange de fichier, c'est uniquement nécessaire si l'on souhaite faire de l'échange de fichier sans que les personnes soient connectées en même temps.

    D'ailleurs, pour ceux qui ne se sentent pas de gérer leur propre serveur, Rsync.net offre une réduction sur ses offres d'hébergement spécifiquement pour les utilisateurs de Git-annex : http://www.rsync.net/products/git-annex-pricing.html

    Il est aussi possible d'utiliser Tahoe-LAFS comme outil d'hébergement/sauvegarde avec Git-annex :
    http://git-annex.branchable.com/special_remotes/tahoe/

    Actuellement il y a des réflexions pour utiliser Bittorrent ou telhash :

    http://git-annex.branchable.com/todo/Bittorrent-like_features/
    http://git-annex.branchable.com/forum/Wishlist:_Bittorrent-like_transfers/
    https://git-annex.branchable.com/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/

    http://git-annex.branchable.com/design/assistant/telehash/

    Sinon Joey Hess a aussi travaillé à simplifier la production d'external special remotes ad-hoc en développant un protocole spécifique :
    http://git-annex.branchable.com/special_remotes/external/

    • [^] # Re: Git-annex a-t-il vraiment besoin d'un serveur ?

      Posté par . Évalué à 2.

      Effectivement, pas besoin de serveur pour utiliser git-annex. Moi je l'utilise pour stocker mes données sur des disques USB, avec pour les données importantes une copie sur au moins 2 disques, sans utiliser de serveur.

  • # Journees du CNRS sur ces thematiques

    Posté par (page perso) . Évalué à 6.

    Des informaticiens du CNRS organisent des journees thematiques. Cette annee le cloud est a l'honneur.

    Il y a deja eu 2 presentations seafile et owncloud, elles sont accessibles a l'adresse :
    http://aramis.resinfo.org/wiki/doku.php?id=pleniaires:pleniere17avril2014

    Une autre journee rediffusee en webcast devrait bientot avoir lieu avec une autre presentation de owncloud :
    http://www.resinfo.cnrs.fr/spip.php?article60

  • # dropbox devrait s'appeller dropbomb à présent

    Posté par . Évalué à -5.

    c'est tout.

  • # bsync

    Posté par (page perso) . Évalué à 5.

    J'ai codé une alternative à Unison il y a quelques mois de cela. Très pratique.

    https://github.com/dooblem/bsync

    • [^] # Re: bsync

      Posté par . Évalué à 2.

      Ton logiciel a l'air vraiment très intéressant, cela vaudrait le coup d'en faire au moins un journal (voire une dépêche !).

      Je n'ai pas très bien compris comment tu détectais les fichiers déplacés (il faut que je me renseigne sur ces histoires d'inodes).

      • [^] # Re: bsync

        Posté par (page perso) . Évalué à 1.

        Merci ;) tu as raison, je vais essayer d'en faire un journal.

        Le numéro d'inode identifie de manière unique un fichier sur un système de fichiers Linux. Si je déplace ou renomme un fichier, ce numéro reste le même, mais son chemin change.

        • [^] # Re: bsync

          Posté par . Évalué à 1.

          Ah ok donc tu fais comme Unison je suppose et tu gardes une liste des inodes quelque part ?

          Enfin bon le plus simple pour comprendre est quand même que je teste.

          Merci

    • [^] # Re: bsync

      Posté par . Évalué à 1.

      Tu devrais changer les termes dans tes exemples, plutôt que

      ./bsync directory1 directory2

      tu devrais écrire dans ton message d'aide en ligne et sur ta page github explicative

      ./bsync source destination

      Ça semble logique mais malgré toutes ces années avec des commandes comme tar, cpio, rsync (avec slash ou sans slash) je ne suis jamais sûr.
      À la limite, tu gardes ce côté implicite et tu proposes la possibilité de les spécifier de manière explicite avec des options du type

      ./bsync -s source -d destination.

      Je suis d'accord pour que l'ordi fasse le plus possible le boulot à notre place mais franchement, quand il s'agit synchronisation de fichier, je préfère être sûr de ce que je fais.

      • [^] # Re: bsync

        Posté par (page perso) . Évalué à 2.

        J'ai compris que c'est comme unison donc il n'y a pas de source / destination. Il s'agit de faire la fusion (ou non, au choix) des deux arborescences…

        • [^] # Re: bsync

          Posté par . Évalué à 1.

          J'ai compris que c'est comme unison donc il n'y a pas de source / destination. Il s'agit de faire la fusion (ou non, au choix) des deux arborescences…

          Comment ça se passe en cas de fichier(s) effacé(s)? Et même dans le cas d'un effacement par erreur? Est-ce restaurable? Un peu à la manière de DropBox, j'ai bizarrement découvert ça récemment.
          En fait, je me rend compte que ma confusion viendrait peut-être d'essayer d'utiliser un tel logiciel en l'assimilant à un logiciel de sauvegarde.

          • [^] # Re: bsync

            Posté par (page perso) . Évalué à 2.

            Dans unison, tu as chaque dossier dans deux colonnes et des flèches au centre soit vers la droite, soit vers la gauche…. Tu acceptes, modifies comme tu veux et lance (go) la synchro…

            Il y a des options pour y aller en automatique et laisser le soft faire le meilleur choix avec ce qu'il est capable de savoir. Il ne pourra jamais savoir que tu as fait une erreur…

            Bref, c'est de la synchro bi-directionnelle, pas du backup.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.