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 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
- 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.
Aller plus loin
- Site officiel de Seafile (2817 clics)
- Page du projet sur GitHub (296 clics)
- Démonstration de l'interface web (2069 clics)
- Wiki technique (467 clics)
- Tutoriel d'installation de Seafile (1119 clics)
# Re-motivation
Posté par SaintGermain . É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 realitix (site web personnel) . É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 Xaapyks . É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 obsidien . Évalué à 10.
Parmi les principaux défauts, je dirais :
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 :
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 Astaoth . Évalué à 1.
Comme point négatif, je dirais qu'il manque une version FreeBSD.
Emacs le fait depuis 30 ans.
# Jamais réussi à la faire fonctionner
Posté par daeavelwyn . Évalué à 5. Dernière modification le 25 avril 2014 à 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.
[^] # Re: Jamais réussi à la faire fonctionner
Posté par Pi3R1k . Évalué à 6.
Quand je lit un commentaire de ce type, je me dit : cette personne est incapable de lire et d'appliquer une procédure….
Si tous les projets libres était aussi bien document que Seafile ce serait le pied.
Le scrit d'init, la conf apache, de nginx (et bien d'autres choses) sont fournies pour différentes distributions ici : https://github.com/haiwen/seafile/wiki
[^] # Re: Jamais réussi à la faire fonctionner
Posté par ze_farf . Évalué à 5.
La procédure d'upgrade est des plus simple, je l'ai faite encore hier : couper le service, un script à jouer, lancer le service.
Sinon en suivant les différentes docs cela roule vraiment tout seul : https://github.com/haiwen/seafile/wiki
Redirection nginx 443 vers 8000 sans soucis, chiffrement ok : https://github.com/haiwen/seafile/wiki/Enable-Https-on-Seafile-web-with-nginx
Lancement des services en auto : https://github.com/haiwen/seafile/wiki/Start-seafile-server-at-system-bootup
Je comprends que cela puisse laisser perplexe car cela sort de l'ordinaire et ne se limite pas qu'à faire du web.
# Migration depuis la 2.1
Posté par Jean-Max Reymond (site web personnel) . Évalué à 3. Dernière modification le 25 avril 2014 à 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 SaintGermain . É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 Jean-Max Reymond (site web personnel) . É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 SaintGermain . Évalué à 5.
Pourtant je crois que PostgreSQL est la base de données recommandée par Django (et Seafile utilise Django).
Au hasard :
# Interessant, mais..
Posté par isildur37 . É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.
[^] # Re: Interessant, mais..
Posté par Nicolas Raoul (site web personnel) . Évalué à 3.
Je suis moi aussi en train de chercher, il y a 2 semaines j'ai posé la question sur Software Recommendations à tout hasard.
Mon avant-dernière dépêche listait 2 outils qui se veulent être des remplacements libres de BitTorrent Sync: syncthing que tu as cité, et ClearSkies.
[^] # Re: Interessant, mais..
Posté par André Rodier . Évalué à 2.
Il y a aussi SparkeShare (http://sparkleshare.org/)
Je ne l'ai pas encore testé, je suis satisfait d'owncloud pour le moment.
[^] # Re: Interessant, mais..
Posté par Albert_ . Évalué à 2.
Fortement deconseille pour les fichiers binaires.
[^] # Re: Interessant, mais..
Posté par flagos . Évalué à 5.
Je déconseille sparkleshare. Ca marche plutot bien au debut, en mode mono ou 2 clients. Mais des que tu essaies de t'en servir un peu plus en intensif, ca se met a plantouiller. J'ai laissé des gens non geeks s'en servir, ils ont eu des bugs de resynchro et j'ai eu plus d'une fois des disparitions de fichiers.
Malgré que le projet soit séduisant, on sent vraiment que la manière dont sparkleshare utilise git est casse gueule.
# Premiers pas avec Seafile.
Posté par RoyalPanda . É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 Michel H . É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
[^] # Re: Ubuntu One
Posté par rakoo (site web personnel) . Évalué à 4.
Tu vas être content d'apprendre qu'il y a une implémentation de référence libre du protocole, alors.
# Et niveau perfs ?
Posté par Reihar . É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 obsidien . Évalué à 4.
Je n'ai pas fait de benchmark, mais voici deux points qui jouent à mon avis en faveur de Seafile :
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 Larry Cow . Évalué à 1.
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.
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 obsidien . É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 Sytoka Modon (site web personnel) . Évalué à 2.
Un système comme glusterfs en sous main est capable de découper en petits morceaux de manière transparente.
[^] # Re: Et niveau perfs ?
Posté par Xaapyks . É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 Gof (site web personnel) . Évalué à 4.
Quel est l'avantage de découper les fichiers en bloc ? Pourquoi est ce plus performant ?
[^] # Re: Et niveau perfs ?
Posté par Guillaume D. . Évalué à 2.
https://linuxfr.org/news/seafile-un-dropbox-like-libre-a-heberger-sort-en-version-3#comment-1535024
[^] # Re: Et niveau perfs ?
Posté par Kerro . Évalué à 2.
Le commentaire que tu pointes dit juste que c'est génial et très performant. Mais pourquoi ?
[^] # Re: Et niveau perfs ?
Posté par CrEv (site web personnel) . Évalué à 2.
je ne sais pas dans le cas de seafile mais de manière générale découper en plusieurs blocs peut avoir comme intérêt d'éviter de faire de la duplication (en gros si deux blocs sont identiques un seul est enregistré) et on peut peut-être imaginer la même chose lors de la synchro, ce qui pourrait réduire la quantité de données à télécharger.
[^] # Re: Et niveau perfs ?
Posté par Guillaume D. . Évalué à 3.
Lis les liens !
Je ne vais pas te recopier ici les 15 pages …
[^] # Re: Et niveau perfs ?
Posté par a-wai (site web personnel) . Évalué à 4. Dernière modification le 26 avril 2014 à 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 Sytoka Modon (site web personnel) . É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 CrEv (site web personnel) . Évalué à 2.
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 Sytoka Modon (site web personnel) . É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 karteum59 . É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 Guillaume D. . É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 Xaapyks . É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 obsidien . É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 Xaapyks . É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 obsidien . É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 :
[^] # Re: Sécurité
Posté par Xaapyks . Évalué à 2.
OK merci.
Du coup je ne vois pas trop l'intérêt en fait…
[^] # Re: Sécurité
Posté par jeberger (site web personnel) . É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 obsidien . É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 Anonyme . Évalué à 3.
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 djano . Évalué à 4.
Il manque quelques mots ici.
[^] # Re: Typo
Posté par obsidien . Évalué à 3.
Exact, merci. Par contre, c'est ma première dépêche et je ne sais pas si je peux l'éditer et comment ?
[^] # Re: Typo
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Seul un modérateur peut éditer une dépêche une fois publiée. Quels étaient les mots prévus ici ?
[^] # Re: Typo
Posté par obsidien . Évalué à 2.
Initialement, le contenu était :
Voici quelques unes des nombreuses fonctionnalités de Seafile.
# Upload anonyme
Posté par SaintGermain . É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 obsidien . É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 SaintGermain . É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 Letho . É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 bobert . Évalué à 0.
Alors, du coup, qu'en est-il ? Tu as essayé ?
# Proxy HTTP
Posté par sifu . É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 Nico C. . É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 Jean-Max Reymond (site web personnel) . É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 Nico C. . Évalué à 1.
La base de données fait quelle taille avec un tel volume ?
[^] # Re: Retours d'experience stabilité et volumes
Posté par obsidien . É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 nettlebay (site web personnel) . É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
[^] # Re: Site Seafile vulnérable à Heartbleed SSL bug
Posté par Malizor . Évalué à 1.
C'est vrai que ça fait un peu tache…
Je viens de leur signaler sur Twitter.
[^] # Re: Site Seafile vulnérable à Heartbleed SSL bug
Posté par Malizor . Évalué à 1.
Corrigé !
Explication officielle :
# Très intéressant mais ...
Posté par JC (site web personnel) . É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 Sytoka Modon (site web personnel) . É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 flan (site web personnel) . É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 Sytoka Modon (site web personnel) . É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 flan (site web personnel) . É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 Kwiknclean . Évalué à 1.
Quelqu'un a t-il essayé de l'installer dans une jail BSD sous freenas ?!
# bitbucket
Posté par barmic . É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 ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Ports "exotiques"
Posté par H4wkmoon . É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 barmic . É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).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ports "exotiques"
Posté par Juke (site web personnel) . Évalué à 3.
et chez ces gros clients il est autorisé de faire passer n'importe quoi par 443 ?
# FileZ : plus light et efficace
Posté par friton . É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 Nicolas Raoul (site web personnel) . É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:
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.