Seafile, un Dropbox-like libre à héberger sort en version 3

63
25
avr.
2014
Cloud

Suite à la dépêche présentant les alternatives à Dropbox, , qui évoquait Seafile, il semble intéressant de présenter de façon plus approfondie ce logiciel.
Seafile

Seafile est une solution de synchronisation et de partage de fichiers bâtie sur trois composants :

  • un serveur, Seafile (sous licence GPLv3) ;
  • une interface web, SeaHub (sous licence Apache), permettant de consulter les fichiers gérés par Seafile directement via le web ;
  • un client de synchronisation.

Le projet utilise un modèle inspiré de Git pour la gestion de fichiers, avec certaines adaptations, permettant par exemple de gérer de façon plus performante les gros fichiers.

Éditions

Deux éditions de Seafile sont disponibles :

  • une édition communautaire, sous licence libre, qui est l'objet de cette dépêche ;
  • une édition entreprise, payante, qui rajoute principalement la recherche plein texte, la visualisation des documents Microsoft Office et la prise en charge de la clusterisation.

Fonctionnalités

Seafile dispose de nombreuses fonctionnalités, que l'on peut répartir en trois catégories : serveur, interface web et client.

Serveur

Quelques propriétés du serveur :

  • installable sur Windows et Linux ;
  • multi-utilisateurs ;
  • chaque utilisateur peut avoir plusieurs bibliothèques de fichiers ;
  • système de groupes, un groupe peut avoir ses propres bibliothèques ;
  • serveur WebDAV ;
  • support du chiffrement des bibliothèques côté client (via mot de passe) ;
  • support de HTTPS ;
  • les fichiers peuvent être versionnés ;
  • possibilité de fixer un quota d'espace disque pour les utilisateurs.

Interface web

Accueil de l'interface web

  • installable sur Windows et Linux ;
  • multilingue ;
  • support de HTTPS ;
  • partage de fichiers/dossiers en lecture via lien public (avec envoi automatisé par mail) ;
  • système de lien public permettant à un utilisateur non authentifié de mettre en ligne des fichiers directement dans une bibliothèque Seafile (très pratique pour récupérer des fichiers lourds qui ne passent pas par mail, des packs de photos, etc.) ;
  • accès à l'historique des modifications des fichiers, dossiers et bibliothèques, et possibilité de les restaurer à un état antérieur en un clic ;
  • éditeur de texte minimaliste pour les fichiers textes/Markdown ;
  • module permettant d'héberger un wiki en Markdown, synchronisable et éditable en local comme une bibliothèque standard ;
  • téléchargement par fichier mais aussi par dossier (sous forme d'archives) ;
  • corbeille permettant de restaurer des éléments supprimés ;
  • messagerie en ligne (en groupe ou avec un utilisateur particulier) ;
  • prévisualisation/consultation de certains fichiers directement dans le navigateur : musique, texte, PDF, images…

Client

  • compatible Windows, Mac, Linux, Android et iOS ;
  • possibilité de synchroniser seulement certaines bibliothèques ;
  • possibilité de synchroniser des bibliothèques depuis différents serveurs Seafile ;
  • possibilité de fixer une limite pour les vitesses d'envoi et de réception ;
  • possibilité d'ignorer certains fichiers ou patterns, d'une façon similaire au .gitignore de Git.

Nouveautés de la version 3

La version 3.0 a apporté un certain nombre de changements, principalement dans l'interface qui a été redessinnée pour l'occasion. La gestion des fichiers a été partiellement revue, notamment pour améliorer la rapidité du serveur et de l'interface web.

Pré-requis

Contrairement à certains autres logiciels similaires, comme OwnCloud, Seafile requiert un serveur dédié pour fonctionner, ainsi que Python, l'interface web étant basée sur Django. Côté base de données, Seafile peut fonctionner avec SQLite, MySQL et PostgreSQL. SQLite est cependant déconseillée pour des instances de taille importante. Pour le serveur HTTP, Nginx est recommandé, mais on peut tout à fait déployer Seafile avec Apache, comme je l'ai fait.

Conclusion

Dans une optique d'auto-hébergement ou de recherche d'alternatives par rapport à des services centralisés/propriétaires (Google Drive, Dropbox…), Seafile est ainsi une solution tout à fait valable et performante. Que ce soit, d'ailleurs pour une utilisation personnelle ou au sein d'une organisation. Seafile offre également des réponses intéressantes aux problématiques de confidentialité, grâce à l'utilisation possible de HTTPS et du chiffrement des bibliothèques côté client.

Étant un utilisateur satisfait de Seafile depuis plusieurs mois, je vous invite à garder un œil sur ce projet vraiment bluffant.

  • # Re-motivation

    Posté par . Évalué à 7.

    Merci pour cette dépêche très intéressante. J'avais essayé d'installer Seafile il y a un an et quelques mais j'avais lamentablement échoué (procédure trop complexe ou incompétence de ma part, à vous de choisir).

    Cette dépêche me donne envie de retenter !

    Afin de répondre à un commentaire disant que l'on avait trop tendance à cacher les défauts des logiciels libres, est-ce que tu pourrais donner un bref retour sur les bogues actuels, les limitations, les problèmes d'ergonomie, etc.

    Bref les points négatifs ?
    À moins que le logiciel soit proche de la perfection…

    Merci !

    • [^] # Re: Re-motivation

      Posté par . Évalué à 4.

      Bonjour,
      J'utilise moi aussi Seafile depuis plusieurs mois et je n'ai rencontré aucun bug! (1 seul mais c'était nginx qui était mal configuré).
      Le seul point négatif pour moi est que l'application Android ne permet pas de synchroniser automatiquement les photos, il faut les sélectionner manuellement.
      Que du bon!

      • [^] # Re: Re-motivation

        Posté par . Évalué à 4.

        Voilà je viens d'installer le serveur sur une debian : C'était vraiment hyper simple !
        Le client sur ArchLinux : déjà plus galère avec toutes les dépendances à compiler une par une (mais c'est moi qui me l'impose) et ça marche parfaitement ! La synchro semble très efficace et rapide.
        Le client sur Android: ça marche mais effectivement je rejoins ton commentaire : Le fait que ça ne synchronise pas tout seul les dossiers et qu'il faille passer par l'interface de l'application est un show stopper pour moi.

        Ça ne m’empêchera pas de l'utiliser sur PC mais sur android qu'en cas de fort besoin…

    • [^] # Re: Re-motivation

      Posté par . Évalué à 10.

      Parmi les principaux défauts, je dirais :

      • Une installation pas forcément facile pour tout le monde, car serveur dédié + Django pour l'interface web. Même si c'est pour moi largement compensé par la clarté de la documentation, je comprends que ça puisse être dissuasif par rapport à des logiciels comme OwnCloud, où on balance les fichiers par FTP sur son mutualisé et hop.
      • Manque (à mon avis) de certaines fonctionnalités aux niveau de l'interface web : barre de recherche (présente uniquement dans la version payante), partage protégé par mot de passe, lien de partage avec date d'expiration, édition de documents ODF en ligne. Ce sont des choses présentes dans OwnCloud qui me manquent parfois. Après, on peut quand même faire sans, pour moi ce n'est pas bloquant
      • Le fait qu'il y ait une édition gratuite, libre et une édition payante. Je trouve ça dommage, même si je comprends tout à fait les raisons de ce choix.

      A côté de ça, pour être honnête, la qualité de ce soft est proprement hallucinante. Certes, Seafile est centré sur les fichiers (pas de calendrier, flux RSS, etc.), mais il le fait bien :

      • La synchronisation est vraiment hyper-rapide (le client détecte les modifs en quelques secondes et reste peu gourmand en ressources)
      • jusqu'à maintenant, je n'ai jamais eu de problème de conflits de fichiers (alors que j'en avais tout le temps avec OwnCloud)
      • Tout est fait pour préserver au maximum les données des utilisateurs (historique, versionning, corbeille avec restauration en un clic).
      • Les migrations sont presque un moment de plaisir. J'ai migré de la 2.1 à la 3.0 en une demi-heure, parce que je suis lent

      Pour info, je fais tourner Seafile depuis environ 9 mois, sur un Kimsufi 2G, avec un total de 20Go de fichiers répartis dans 5 bibliothèques (certaines contiennent plus de 30 000 fichiers). L'interface web peine au premier affichage, lorsque l'arborescence est trop complexe/profonde, mais c'est à peu près tout.

      • [^] # Re: Re-motivation

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

        Comme point négatif, je dirais qu'il manque une version FreeBSD.

        Opera le fait depuis 10 ans.

  • # Jamais réussi à la faire fonctionner

    Posté par . Évalué à 5. Dernière modification le 25/04/14 à 09:50.

    Alors, vraiment super projet, mais sur le papier en ce qui me concerne, parce que j'ai passé un temps fou à le faire marcher avec Apache et encore j'ai pas trop réussi (pb avec l'interface web et le rewriting), synchro des dossiers mais pas des fichiers qu'ils contiennent (O-o") et alors quand en plus j'ai voulu sécuriser tout ça en utilisant une config ssl (qui par ailleurs fonctionne avec mes autres sites/soft) alors là, c'est juste l'enfer !

    Sans parler des commandes/dossiers dont le nommage se ressemblent empêchant l'utilisation optimum de la touche tab d'auto completion parce que entre sudo ./seafile.sh start et sudo ./seahub.sh start avec dans le même dossier que ces scripts un dossier seahub et un dossier seafile…. Puis le fait de devoir sans cesse naviguer dans l'arborescence pour trouver les différents fichiers de config (ccnet.conf ou seahubjenesaisplusquoi.py)

    Le coup de la redirection en local vers le port 8000 aussi, ça n'a pas marché pour moi. De ce que j'ai compris, la requête extérieur arrive sur le port 443 d'apache qui la redirige via la config vhost vers 127.0.0.1:8000 …enfin qui la redirige parfois.

    Les logs ne m'ont été d'aucun secours hélas.

    Bref, un enfer à installer pour un utilisateur lambda comme moi ! Dommage, ça à l'air vraiment bien comme projet, mais faudrait vraiment revoir l'installation (et l'upgrade !), pour la rendre un peu plus accessible.

  • # Migration depuis la 2.1

    Posté par (page perso) . Évalué à 3. Dernière modification le 25/04/14 à 09:51.

    J'avais installé il y a quelques semaines seafile 2.1, suite à l'abandon de Ubuntu One et des retours très favorables depuis linuxfr. Si j'avais abandonné l'installation de la version postgreSql qui ne semble pas finalisée, l'installation de la version Mysql s'est passée comme un charme et depuis, il y a une dizaine d'utilisateurs Linux et Windows qui sont enchantés.
    J'avais un peu peur avec une nouvelle version 3.0 mais l’installation est très pro: sur le serveur, il y a un répertoire upgrade dans lequel on trouve tous les scripts de migration. Ensuite, chaque poste client a installé son logiciel client par exemple avec le .deb pour les postes Ubuntu et en dix minutes, tout était à niveau.
    L'interface Web est toujours OK avec par exemple, l'affichage d'un .odt dans le navigateur Web :-)
    Bref, nickel: un logiciel efficace qui sait se faire oublier

    • [^] # Re: Migration depuis la 2.1

      Posté par . Évalué à 2.

      Je dois être masochiste à vouloir toujours utiliser PostgreSQL au lieu de MySQL (avec Owncloud et Seafile).
      Je crois que je vais laisser tomber et me rabattre sur MySQL comme tout le monde, j'aurai moins de problèmes !

      • [^] # Re: Migration depuis la 2.1

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

        Hélas,PostgreSql a du mal à s'imposer parmi les développeurs du libre. Du coup, je vais prendre un peu de temps pour voir ce qui cloche entre Seafile et PostgreSql et faire le retour aux développeurs.

        • [^] # Re: Migration depuis la 2.1

          Posté par . Évalué à 5.

          Pourtant je crois que PostgreSQL est la base de données recommandée par Django (et Seafile utilise Django).

          Au hasard :

          If you’re not tied to any legacy system and have the freedom to choose a database backend, we recommend PostgreSQL, which achieves a fine balance between cost, features, speed and stability.

  • # Interessant, mais..

    Posté par . Évalué à 2.

    Je suis un gros utilisateur de dropbox, ayant partiellement switche sur owncloud que je suis depuis le debut.
    Owncloud est pratique pour les fichiers non vitaux. La replication est(etait?) vraiment penible a configurer quand j'ai essaye. Du coup je n'ai jamais totalement migre.
    Dropbox offre pour ma part la securite pour la replication de documents que je ne peux pas me permettre de perdre. Que je chiffre bien sur avant de les mettre dessus.

    J'ai recemment teste bitsync, et c'est juste magique:
    - Replication ultra-simple
    - pas de notion client/server, tout est l'un et l'autre a la fois
    - api disponible ( et documentee)
    - multi-plateforme
    Malheureusement, non libre. Du coup j'ai ajoute une couche de cryptage perso pour m'assurer de la fiabilite que je mettrai peut-etre sur github dans quelques temps.

    Je suis en train de chercher une alternative libre qui offre la meme simplicite d'utilisation (syncthing est une piste). Neanmoins pour le moment, rien de tres concluant la dessus.

  • # Premiers pas avec Seafile.

    Posté par . Évalué à 5.

    J'ai personnellement tenté une installation après la dépêche sur Dropbox. Aucun soucis pour moi. Procédure simple avec un script bash qui fait presque tout le boulot, et qui explique ce qu'il ne fait pas. La synchronisation avec le serveur LDAP m'a pris 30 secondes : un copier / coller du wiki et le changement des adresses IP, mot de passe, etc…
    L'installation du client Linux ne m'a posé aucun problème non plus.

    En résumé : je ne connaissais pas avant hier, et je suis agréablement surpris. Ce me semble plus ergonomique qu'Owncloud que j'utilisais jusqu'alors seulement en utilisation perso. Seafile je pense fera l'affaire en pro, suivant son comportement en monté en charge, pas si énorme que ça je précise.

    NB: Conditions d'install : Wheezy fraîche pour l'occasion, aucun changement par rapport à l'installation recommandée, DB: MySQL

  • # Ubuntu One

    Posté par . Évalué à 2.

    Dans la liste des alternatives, Ubuntu One n'a pas été cité il me semble.

    Le code du serveur n'est encore disponible mais suite à la décision de fermeture du service, Canonical a annoncé sa libération prochaine [1].

    J'ai testé ce service il y a quelques années, et je trouvais son intégration bien faite. Le "sapucpaslibre" m'a fait l'abandonné à l'époque et j'attends avec impatience de pouvoir tester la version libre du serveur.

    [1] http://blog.canonical.com/2014/04/02/shutting-down-ubuntu-one-file-services

  • # Et niveau perfs ?

    Posté par . Évalué à 4.

    Alors, c'est comment ? J'avais essayé de faire tourner un owncloud sur une machine peu puissante et ça passait vraiment pas du coup je me demande. Est-ce que Seafile est performant ?

    • [^] # Re: Et niveau perfs ?

      Posté par . Évalué à 4.

      Je n'ai pas fait de benchmark, mais voici deux points qui jouent à mon avis en faveur de Seafile :

      • OwnCloud est écrit en PHP, Seafile est écrit principalement en C pour la synchronisation, (et Python/Django pour l'interface web)
      • OwnCloud stocke les fichiers tels quels, Seafile les découpe en blocs pour optimiser l'espace et le versionning

      Mon utilisation personnelle me prouve que Seafile est largement plus rapide qu'OwnCloud. Sur un Kimsufi 2G avec plus de 20Go de fichiers (voir mon commentaire plus haut) la synchronisation est toujours quasiment instantanée.

      Donc pour répondre à ta question, je dirais que oui, Seafile est performant.

      • [^] # Re: Et niveau perfs ?

        Posté par . Évalué à 1.

        OwnCloud est écrit en PHP, Seafile est écrit principalement en C pour la synchronisation, (et Python/Django pour l'interface web)

        Ta comparaison est foireuse : la synchro d'OwnCloud se fait essentiellement côté client, et en C (ou C++, pas vérifié) dans le cadre de csync et mirall.

        OwnCloud stocke les fichiers tels quels, Seafile les découpe en blocs pour optimiser l'espace et le versionning

        C'est à double tranchant : c'est un gros plus pour les performances, mais ça perd beaucoup en souplesse. Sans compter que ça peut se gérer au niveau FS indépendamment de l'outil, je suppose.

        • [^] # Re: Et niveau perfs ?

          Posté par . Évalué à 1.

          Effectivement, je ne suis peut-être pas compétent pour juger, donc tu as peut-être raison, mais il me semble que la synchronisation ne peut pas se faire uniquement côté client : il faut bien interroger le serveur pour savoir quels sont les fichiers à syncrhoniser, etc. OwnCloud côté serveur est entièrement en PHP, donc par rapport à Seafile dont l'outil de synchronisation est en C, je pense qu'il y a malgré tout un net avantage en terme de rapidité pour Seafile sur ce point.

          Pour le découpage en blocs, je suis d'accord avec toi, le gain de performances se fait au détriment de la souplesse.

        • [^] # Re: Et niveau perfs ?

          Posté par . Évalué à 4.

          Si par "souplesse" tu évoques la perte de transparence côté FS pour un admin, et donc de l'accès aux fichiers, j'ai vu qu'il y avait un module FUSE qui (si j'ai bien compris) permet d'explorer les bibliothèques depuis un montage dans le FS.

      • [^] # Re: Et niveau perfs ?

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

        Owncloud stocke les fichiers tels quels, Seafile les découpe en blocs pour optimiser l'espace et le versionning

        Quel est l'avantage de découper les fichiers en bloc ? Pourquoi est ce plus performant ?

    • [^] # Re: Et niveau perfs ?

      Posté par . Évalué à 4. Dernière modification le 26/04/14 à 01:14.

      Je l'utilise en remplacement d'Owncloud sur un Beaglebone Black (à peine plus puissant qu'un RasPi), et y'a pas photo : Seafile gagne haut la main !

      La grosse différence vient probablement du langage : PHP (donc quasi-systématiquement parsé et interprété) pour Owncloud, Python (compilé en bytecode et exécuté sur une VM) pour Seafile, dans ce cas la VM Python gagne haut la main.

      Je précise que ce n'est pas faute d'avoir essayé d'optimiser les perfs d'Owncloud, notamment via l'utilisation de memcache et php-apc. Au pifomètre, je dirais que l'avantage de Seafile sur Owncloud sur ma config est de l'ordre de :
      - x2/x3 par rapport à un PHP "de base"
      - x1.5 (au moins) si on utilise apc et memcache pour Owncloud

      Bref, j'ai switché pour les perfs, et j'ai fait le bon choix…

      (Côté client je n'ai pas comparé par contre, mon problème concernant uniquement le serveur)

      • [^] # Re: Et niveau perfs ?

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

        J'avais fais des tests en Matlab et en Perl, la compilation fait gagner la génération du bytecode mais ensuite, on va à la même vitesse. Les serveurs web savent gérer cette problématique s'il le faut…

        Bref, il faut aussi bien choisir ses algo, son API et les modules qu'on utilise.

        • [^] # Re: Et niveau perfs ?

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

          Les serveurs web savent gérer cette problématique s'il le faut…

          un serveur web tout seul comme un grand ne sait pas gérer cela au niveau de PHP. De base en PHP chaque nouvelle requête demande de tout réexécuter. Ensuite il y a les caches d'op-code qui eux améliorent les choses, mais c'est pas juste "les serveurs web savent gérer"

          • [^] # Re: Et niveau perfs ?

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

            Tu chipotes… Je pense au module fastcgi par exemple qui est par défaut dans toute distribution. Évidement, si tu ne rentres pas un peu dans la configuration, tu n'es pas en mode optimum coté perf (et puis, il faut que le code soit conçu un minimum pour).

      • [^] # Re: Et niveau perfs ?

        Posté par . Évalué à 4.

        La vitesse est une chose, mais qu'en est-il de l'occupation mémoire ?
        J'ai l'intention de mettre ce genre de dongle sous OpenWRT (Mediatek/Ralink RT5350F à 330 MHz, 4Mo flash pour le système de base et le reste sur USB, 32Mo RAM, ethernet+wifi, 7.5 €). J'ignore si "ça passe" concernant l'usage de Python/Django, notamment du fait des 32 Mo de RAM. Un avis ?

    • [^] # Re: Et niveau perfs ?

      Posté par . Évalué à 4.

      Bonjour,

      Au niveau algo de découpe des fichiers en blocs, et échanges réseau on est vraiment sur ce qui ce fait de mieux.
      C'est la même technique que BUP : https://github.com/bup/bup/blob/master/DESIGN , qui consiste à découper les données en blocs dont la taille est variable et portée par les données elles-même.
      On fait glisser (FIFO) une fenêtre de taille fixe (48 octets) sur les données, une somme de contrôle est générée à chaque pas, dès que l'on a une empreinte prédéfinie, c'est la fin d'un bloc. On calcule la somme de hachage sur ce bloc. Cette somme est transmise au client/serveur si elle est connue, le bloc en question est reconstituée par celui déjà connu, si non le bloc est transféré.
      Pour plus d'information lire : http://pdos.csail.mit.edu/papers/lbfs:sosp01/lbfs.pdf .

      La partie découpage en bloc a l'aide de la fenêtre glissante, et découpe en fonction de la somme de contrôle de cette fenêtre est vraiment géniale de simplicité et d'efficacité comme algo !!!

      Je viens de mettre 2Go de fichiers répartis en 38000 fichiers "jpg" sur un RPi, et c'est très fluide et rapide.

  • # Sécurité

    Posté par . Évalué à 2.

    C'est très intéressant ! Merci pour la dépêche.

    Qu'en est-il de la sécurité des communications entre le client lourd et le serveur ? C'est chiffré ?

    Peut-on gérer des systèmes de clés avec révocation si par exemple on perd son smartphone android avec une bibliothèque configurée ?
    Au moins, ne plus recevoir de mises à jour et ne pas pouvoir écrire. (Le top serait l'auto destruction sur révocation, mais encore faut-il que le client ait l'info avant l'accès hors ligne aux données…)

    • [^] # Re: Sécurité

      Posté par . Évalué à 1.

      Pour ta première question :

      La synchronisation se fait sur HTTP et supporte également HTTPS donc tu peux chiffrer si tu le souhaites. De même, il est possible de créer des bibliothèques chiffrées côté client, par mot de passe. Ce mot de passe n'est pas stocké sur le serveur, ce qui permet de rajouter une couche de protection.

      Pour ta deuxième question, il est possible de révoquer l'accès pour les clients. On le voit vaguement sur la capture d'écran de l'interface web, ikl y a un onglet "Clients" à gauche, qui te permet de lister tous les clients connectés à ton compte et de les désactiver.

      • [^] # Re: Sécurité

        Posté par . Évalué à 2.

        Merci.
        En effet, j'aurais du m'en douter, comme git sait communiquer sur HTTPS. C'est un bon point :-)

        Le chiffrement chez le client aussi, mais du coup on n'a plus accès aux fichiers via les navigateurs de fichiers classiques ? Il faudra toujours passer via l'application cliente qui sait déchiffrer et ouvrir la bibliothèque ?
        Ou bien ça met en place une sorte vfs déchiffré qui permet de se raccrocher sur le vfs, à la manière d'un gvfs ou d'un quelconque montage à la fuse ?

        • [^] # Re: Sécurité

          Posté par . Évalué à 1.

          Je crois que j'ai dis une bêtise : la synchronisation client serveur ne passe pas par HTTP/S.

          J'ai du mal à trouver des informations sur le protocole utilisé. Cette page de documentation explique les interactions entre les différents composants de Seafile, mais pas d'infos sur le protocole proprement dit.

          Je vais leur poser la question sur la mailing list et je te dis ça.

          Concernant le chiffrement côté client je viens de tester et ça marche comme ça :

          1. Tu crée ta bibliothèque (via le client lourd ou l'interface web) en cochant le case chiffrement et en fournissant un mot de passe
          2. Tu peux accéder à ta bibliothèque via l'interface web en renseignant ton mot de passe. De mémoire, il n'est pas stocké, peut être mis en cache pour une courte durée.
          3. A partir du client local, tu peux télécharger la bibliothèque chiffrée, en renseignant ton mot de passe. Je pense qu'il est gardé en mémoire par le client lourd, qui l'utilise pour chiffrer les informations transmises au serveur. Tes fichiers en local sont accessibles comme n'importe quels autres fichiers, depuis l'explorateur de fichier (pas besoin de passer par le client).
          • [^] # Re: Sécurité

            Posté par . Évalué à 2.

            OK merci.
            Du coup je ne vois pas trop l'intérêt en fait…

            • [^] # Re: Sécurité

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

              Ça te permet d'héberger ton seafile sur un serveur cloud public (Amazon par ex.) sans que l'hébergeur puisse accéder à tes fichiers (puisqu'il ne les voit jamais en clair).

        • [^] # Re: Sécurité

          Posté par . Évalué à 5.

          Okay, je viens de faire quelques recherches et il semble que même si la communication client/serveur ne passe par par HTTP/S, il y a bel et bien chiffrement. D'après ce document :

          Every seafile desktop client has a unique private key. When a client and a server connect, they will exchange public key and negotiate a session key. The session key is derived from cryptographically secure random number with PDKDF2 algorithm. And it's exchanged between the client and the server with RSA encryption. This session key will be used to encrypt the data transfer with AES-256/CBC algorithm.

          Soit, si on traduit en gros :

          Chaque client de bureau possède une clé privée unique. Quand un client et un serveur sont connectés, ils échangent leur clé publique et génèrent une clé de session. Cette clé de session est dérivée d'un algorithme de génération de nombre aléatoire. Elle est échangée entre le client et le serveur avec un chiffrement RSA. Cette clé de session est utilisée pour chiffrer les données transmises avec l'algorithme AES-256/CBC.

          Personnellement, ça me paraît correct, mais je ne suis pas forcément le plus calé sur la question. D'autres avis ?

          • [^] # Re: Sécurité

            Posté par . Évalué à 3.

            Personnellement, ça me paraît correct, mais je ne suis pas forcément le plus calé sur la question. D'autres avis ?

            J'aurais plus confiance si ils s'étaient basés sur un protocole deja existant et connu pour etre fiable (ssh, tls ou autre) plutot que réimplementer leur truc.

  • # Typo

    Posté par . Évalué à 4.

    Fonctionnalités
    
    Seafile dispose de nombreuses fonctionnalités de , qu'on peut répartir en [...snip...]
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    

    Il manque quelques mots ici.

  • # Upload anonyme

    Posté par . Évalué à 1.

    Tiens une question à ceux qui s'y connaissent avec Seafile.

    Une fonction très intéressante pour moi est l'upload anonyme.

    L'idée est de que tout le monde puisse uploader ses photos après un évènement sans avoir à créer de compte.
    On aurait juste à donner une URL avec un mot de passe et une personne peut se connecter, dire éventuellement qu'elle s'appelle Tata Ginette (ou créer un répertoire Tata Ginette) et envoyer toutes ses photos.

    Cela existait je crois sur Dropbox et a été supprimé (pour raison légales). Avec un logiciel libre on a moins de contrainte, donc ce serait chouette !

    Merci

    • [^] # Re: Upload anonyme

      Posté par . Évalué à 2.

      Cela existe sur Seafile (lien d'envoi), mais c'est limité à l'envoi de fichiers (pas de création de dossier), et non protégé par mot de passe.

      • [^] # Re: Upload anonyme

        Posté par . Évalué à 4.

        Ok je suppose que le lien d'envoi est avec une sorte de hash, donc cela pourrait convenir.
        C'est plus embêtant de ne pouvoir créer de répertoire mais cela peut se résoudre.

        On voit vraiment les avantages du logiciel libre : pas de contraintes artificielles venant d'Hollywood et possibilité d'ajouter des fonctions (pour peu que l'on soit motivé).

        Merci beaucoup !

  • # Lan sync ?

    Posté par . Évalué à 9.

    Pour moi, une des killers-features de Dropbox, c'est le lan-sync.
    En gros, plutôt que d'aller chercher le fichier sur le serveur Dropbox, le client vérifie d'abord s'il n'est pas disponible sur un ordinateur du réseau local. Beaucoup plus rapide, donc.

    Si Seafile gère cela, je switche dans la soirée :)

    Plus d'infos : https://www.dropbox.com/help/137/fr

    • [^] # Re: Lan sync ?

      Posté par . Évalué à 0.

      Alors, du coup, qu'en est-il ? Tu as essayé ?

  • # Proxy HTTP

    Posté par . Évalué à 3.

    A l'époque, j'avais oublié car il n'était pas possible de l'utiliser derrière un proxy HTTP.
    J'ai l'impression que le souci est toujours d'actualité:
    https://github.com/haiwen/seafile/issues/168
    Avec Dropbox, je n'ai pas ce problème.

  • # Retours d'experience stabilité et volumes

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

    Qqn a un retour d'experience pour des volumes du genre 35Go d'images et plus ou moins petits fichiers (certains repertoires peuvent accumuler jusqu'a 400000 fichiers) ?
    Et quid de la stabilité ?

    L'objectif serait de synchroniser des données statiques sur frontaux web depuis un ou plusieurs backoffice.

    • [^] # Re: Retours d'experience stabilité et volumes

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

      J'en suis à 80 Go dont au bas mot, 60 Go d'images et cela tourne comme une horloge. Par contre, je n'ai pas de répertoires avec 400 000 fichiers

    • [^] # Re: Retours d'experience stabilité et volumes

      Posté par . Évalué à 2.

      Je pense que Seafile peut supporter de tels volumes de fichiers au niveau de la synchronisation, mais que l'interface web aura parfois du mal à s'afficher.

      Je constate quelques ralentissements de l'interface web chez moi, lorsque les bibliothèques ont trop de fichiers, même s'il y a eu des améliorations avec la version 3. C'est peut-être dû à mon serveur qui est quand même très peu performant, et qui accueille pas mal d'autres logiciels que Seafile.

      Pour la synchronisation proprement dite, je pense que ça peut le faire (mais c'est purement subjectif).

      Sauf erreur de ma part, Seafile ne stocke pas les infos sur les fichiers en base de données : je viens de vérifier les trois bases MySQL utilisées par Seafile, regroupées elles doivent peser quelque chose comme 5Mo. Mon instance Seafile compte environ 20Go de données, et plus de 50 000 fichiers.

      Point de vue stabilité, Seafile n'a jamais crashé chez moi jusqu'à maintenant (côté serveur). Les seules fois où j'ai du stopper le serveur Seafile, c'est pour les mises à jour. Le client est à mon sens peu gourmand en ressources. Chez moi, c'est 1/2% du CPU quand il tourne en fond, il peut monter à 15 ou 30% mais uniquement lors du téléchargement complet d'une bibliothèque ou d'un merge d'une bibliothèque avec un dossier en local.

  • # Site Seafile vulnérable à Heartbleed SSL bug

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

    Bonjour!

    J'ai pas réussi à insérer une capture mais voici l'URL
    http://1.bp.blogspot.com/-MNRBP3rneco/U1qjA4q7jzI/AAAAAAAAJ68/v2E9jQCpKhM/s1600/Capture.png

    Extension Google Chromebleed

    Nettlebay

  • # Très intéressant mais ...

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

    J'ai testé Seafile, il y a un peu plus de 6 mois pour la création d'un Cloud privé.
    J'ai trouvé seafile vraiment intéressant et perfomant : ce qu'il fait, il le fait bien avec de bonnes performances niveau synchro et pas de soucis de conflits (j'avais recalé OwnCloud que j'avais testé aussi)

    Néanmoins de mon point de vue, il reste encore un progrès à accomplir pour que cet outil emporte tous les suffrages (et soir adopté plus largement) : faire une synchro sur des ports usuels.

    En effet comme indiqué plus haut, la synchro client-serveur ne passe pas par des ports usuels (http/https) et du coup c'est bloquant pour des structures qui proposent un filtrage strict (qui ne laisse pas que du http, https, imap et 2 ou 3 autre ports usuels)

    La synchro sur http/https est prévue pour la prochaine version d'après ce qu'il y a écrit ici
    https://seacloud.cc/group/3/wiki/seafile-roadmap-3-x/

    • [^] # Re: Très intéressant mais ...

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

      Et oui, le plaisir des DSI de fermer tous les ports… Du coup, tout passe petit à petit sur le 443 et on crée un sous multiplexeur… Pendant ce temps là, la planète se réchauffe !

      • [^] # Re: Très intéressant mais ...

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

        Tout passer par du HTTP a pas mal d'avantages quand on a une infra un peu compliquée :
        * proxy
        * reverse proxy
        * possibilité de faire du MITM
        * beaucoup d'authentifications possibles (login+mot de passe, mais aussi certificat SSL, kerberos, … sans compter Shibboleth et Webauth)

        Après, pour les perfs, c'est autre chose.

        • [^] # Re: Très intéressant mais ...

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

          Oui, enfin HTTP est verbeux et n'est pas idéal pour tout… Va faire du SSH sur HTTP… Actuellement, je travaille souvent sur une liaison a très bas débit, même SSH a plus que du mal, heureusement j'ai découvert MOSH que je conseille à tous.

          Ensuite, j'ai une application privateur, tout web qu'ils m'avaient dis. Une grosse daube en java non portable (marche avec tel client, pas tel autre, avec telle version…) et impossible de la faire marcher via reverse proxy ou serveur tsock à distance.

          Bref, le HTTP a bon dos et certains mettent dedans vraiment n'importe quoi ;-)

          • [^] # Re: Très intéressant mais ...

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

            Je suis bien conscient des limites du HTTP pour les perfs (d'où ma dernière phrase). Simplement, il ne faut pas en oublier tous les avantages que le HTTP apporte. De temps en temps, c'est bien plus rentable de faire du HTTP que de mettre en place un nouveau protocole ad-hoc qui n'aura pas la moitié de ses fonctionnalités (qui peuvent parfois bien débloquer une situation).

  • # Dans une jail freenas ?

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

    Quelqu'un a t-il essayé de l'installer dans une jail BSD sous freenas ?!

  • # bitbucket

    Posté par . Évalué à 3.

    Il semble que bitbucket (là où sont hébergés les clients) est down… Quelqu'un a un lien pour les télécharger ailleurs ?

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

  • # Ports "exotiques"

    Posté par . Évalué à 1.

    Pour moi, c'est un no-go à cause des ports spécifiques à ouvrir entre le client et le serveur.
    Si la synchro se fait par autre chose que du HTTPS en 443, ce n'est pas la peine.
    Selon le contexte dans lequel vous êtes, il n'est pas toujours possible de faire ouvrir les ports. (Chez un gros client par exemple)

    • [^] # Re: Ports "exotiques"

      Posté par . Évalué à 3.

      C'est vrai que c'est assez contraignant (en plus il ne semble pas bien fonctionner avec tsocks). Il faudrait que les clients supportent des proxy (http(s)/socks).

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

    • [^] # Re: Ports "exotiques"

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

      Selon le contexte dans lequel vous êtes, il n'est pas toujours possible de faire ouvrir les ports. (Chez un gros client par exemple)

      et chez ces gros clients il est autorisé de faire passer n'importe quoi par 443 ?

  • # FileZ : plus light et efficace

    Posté par . Évalué à 0.

    Un outil à la Dropbox, en PHP, made in (f)rance.
    http://gpl.univ-avignon.fr/filez/
    C'est propre, ça fonctionne. ça reste du PHP donc faut y aller mollo en upload…
    Je vous invite à le tester.

    • [^] # Re: FileZ : plus light et efficace

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

      FileZ ne dispose que d'une interface web.
      Tout l'intérêt de Seafile est dans la synchronisation des fichiers entre serveur et local, ce que ne fait pas FileZ.

      Pour facilement ajouter Synchronisation à la Dropbox à la liste des fonctionnalités de n'importe quel serveur de fichiers:

      1. Implémenter le protocole CMIS
      2. Utiliser CmisSync (open source)

Suivre le flux des commentaires

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