Le 8 décembre 2014, la version 4 de Seafile est sortie. Cette solution d'hébergement et de synchronisation de fichiers (à la Dropbox, Google Drive, OwnCloud, pour ne citer qu'eux), publiée sous licence GPL3 s'enrichit ainsi de deux nouvelles fonctionnalités :
- le support de la synchronisation sur HTTP/HTTPS ;
- une nouvelle interface de consultation des fichiers depuis le client (Cloud file browser).
Si vous ne connaissez pas Seafile, je vous invite à faire un tour dans les liens.
Synchronisation sur HTTP/HTTPS
Auparavant, la synchronisation passait par un protocole maison sur des ports peu conventionnels, ce qui pouvait être un facteur bloquant pour certains déploiements, par exemple derrière des pare-feux trop restrictifs. Cette nouvelle fonctionnalité permet donc de s'affranchir de cet obstacle.
Si les questions de sécurité vous préoccupent, la possibilité d'utiliser HTTPS en lieu et place de l'ancien protocole est également une bonne nouvelle, puisqu'on est sur quelque chose de beaucoup plus standard en matière de chiffrement.
Pour le moment, la fonctionnalité n'est pas activée de base sur le client, il faut se rendre dans les paramètres et l'activer manuellement. À terme, elle deviendra l'option par défaut.
Cloud file browser
Cette nouveauté concerne les clients de Seafile pour bureau, dont les nouvelles versions sont publiées au même rythme que celles du serveur.
Auparavant, pour accéder sur un ordinateur aux fichiers d'une bibliothèque non synchronisée sur ce terminal, il fallait passer par l'interface web de Seafile ou par WebDAV. Avec le cloud file browser, il est désormais possible d'interagir avec une bibliothèque non-synchronisée directement depuis le client Seafile, le tout sans la télécharger. Parmi les actions disponibles, on trouve par exemple l'envoi, le téléchargement, la mise à jour ou la suppression d'un fichier, la création d'un lien de partage, le renommage, …
Autres nouveautés
Cette nouvelle version majeure a également été l'occasion d'améliorer certaines choses :
- Côté serveur, le temps d'affichage de certaines pages de l'interface web a été réduit, l'ergonomie de l'outil d'envoi de fichier a été revue, et on peut désormais de fixer une date d'expiration pour les liens de partages.
- Côté client, on retiendra la possibilité de filtrer les bibliothèques par nom (pratique quand on en a beaucoup).
Conclusion
On ne trouve donc pas de fonctionnalité révolutionnaire dans cette nouvelle version, mais un certain nombre d'ajouts sympathiques qui viennent compléter ce qui était déjà présent dans les versions antérieures. Seafile atteint une maturité certaine et constitue une alternative sérieuse et performante face aux solutions de synchronisation existantes.
Si vous avez un bout de serveur sous la main, c'est peut-être le moment d'essayer !
Aller plus loin
- Site officiel (1327 clics)
- Démo publique (768 clics)
- Annonce de la version 4 (83 clics)
- Dépêche LinuxFr.org de la version 3 (186 clics)
- Documentation (89 clics)
- Seafile avec Docker (220 clics)
# BOF
Posté par halfday . Évalué à -10.
Personnellement, une solution qui, quand on l'installe, ouvre au moins 3 ports TCP sur 0.0.0.0, ça me débecte.
Désolé hein, ils font sûrement du bon boulot, mais franchement, l'architecture logicielle est abusée, c'est à revoir.
[^] # Re: BOF
Posté par Tof . Évalué à 6.
Clair, ça obligerait presque à configurer un firewall !
[^] # Re: BOF
Posté par halfday . Évalué à -5.
Heu… Donc pour toi, au lieu de binder sur 127.0.0.1, il faut le faire sur 0.0.0.0 pour "obliger à configurer un firewall" ?
Ca n'a pas de sens :)
[^] # Re: BOF
Posté par gnumdk (site web personnel) . Évalué à 10.
C'est bien connu, la solution de synchro, tu la fais tourner sur 127.0.0.1, comme ça pas de clients, pas d'emmerde…
Et en plus ça montre que tu n'as pas lu la news..
[^] # Re: BOF
Posté par halfday . Évalué à -9.
Justement, vu que le client peut maintenant se synchroniser en HTTP(s), l'archi peut être simplifiée :
Plutôt que d'ouvrir des services, la solution devrait mieux s'intégrer à Apache ou Nginx et proposer cette configuration par défaut, pour n'ouvrir aucun service supplémentaire.
C'est dingue, vous allez m'accuser d'être complètement débile alors que c'est du bon sens.
[^] # Re: BOF
Posté par barmic . Évalué à 8.
Ce n'est pas parce que cette possibilité existe qu'elle devrait être la configuration par défaut.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: BOF
Posté par halfday . Évalué à -10.
Michel Barret, t'es un gros crétin ou quoi ?
"Ce n'est pas parce que la possibilité de ne pas mettre admin comme mot de passe existe que ça devrait être la config par défaut".
Blaireau !
Vas y, ouvre 4 ports TCP sur ta bécane qui abrite tous tes fichiers si tu veux, et passe ton temps à ouvrir les bons ports sur ton iptables, sans te tromper, sans casser la synchro depuis tes devices, très peu pour moi !
[^] # Re: BOF
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Merci de rester courtois dans les échanges, conformément aux règles de modération en vigueur sur le site.
[^] # Re: BOF
Posté par halfday . Évalué à -10.
En plus, faudra m'expliquer pourquoi DEUX services http sont ouverts, l'un pour la synchro et l'autre pour l'interface web.
Faut savoir ce qu'on veut : une solution de synchro efficace et simple à installer, ouverte à tous, ou un truc de geek qu'est TRES contraignant à bien configurer de manière sécurisée (tous les ports http derrière reverse proxy, pas de ports en écoute, sans casser les fonctionnalités, etc.).
tcp 0 0 0.0.0.0:10001 0.0.0.0:* LISTEN 23622/ccnet-server
tcp 0 0 0.0.0.0:8082 0.0.0.0:* LISTEN 23624/seaf-server
tcp 0 0 0.0.0.0:12001 0.0.0.0:* LISTEN 23624/seaf-server
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 23814/python2.7
Et je suis "downvoté" pour souligner ça.
Bravo les gars au niveau sécu.
[^] # Re: BOF
Posté par GnunuX (site web personnel) . Évalué à 4.
C'est quoi le rapport avec la sécu ? Parce qu'un service est derrière un reverse-proxy, le service devient, par magie, sécurisé ?
[^] # Re: BOF
Posté par halfday . Évalué à -10.
Est-ce que j'ai dit ça ?
Je dis simplement qu'il est préférable de ne pas ouvrir des ports alors qu'on peut faire autrement, surtout par défaut !
[^] # Re: BOF
Posté par flan (site web personnel) . Évalué à 3.
Et parce que le port de nginx ne sera pas ouvert, peut-être ?
Concrètement, qu'est-ce que ça change que le port soit ouvert à travers Nginx ou directement par Seafile ?
[^] # Re: BOF
Posté par halfday . Évalué à -10.
GNEIIINNNN ?
Bien sûr que si qu'il est ouvert le port Nginx ! Mais je préfère avoir sur mon serveur un seul port ouvert pour TOUS mes services que 4 ports supplémentaires à la noix avec des démons python qui se lancent sous root sans avertissement scotchés derrière les ports !
Tant de mauvaise foi, c'est abusé. Vous êtes vraiment des glands là.
Vous êtes au courant que le monde se webise ? Non ? Faire des binds TCP c'est has-been tellement c'est pas flexible, vous le savez non ?
[^] # Re: BOF
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Merci de rester courtois dans les échanges, conformément aux règles de modération en vigueur sur le site.
[^] # Re: BOF
Posté par gnumdk (site web personnel) . Évalué à 2.
Wai, t'as raison, c'est trop des glands chez SSH, c'est quoi ce port 22 de merde.
[^] # Re: BOF
Posté par halfday . Évalué à -10.
Mais ok, j'abandonne…
Il y a les Ayatollah du libre qui, dès qu'on critique un peu un projet, crient au scandale.
Seafile est parfait, ça tourne sur 4 ports TCP, c'est l'idéal, impeccable, et très pratique !
Allez A+
[^] # Re: BOF
Posté par sifu . Évalué à 6.
L'absence du support HTTP est quelque chose qui manquait depuis longtemps pour les gens comme moi qui doivent vivre derrière un proxy d'entreprise.
Cependant, il ne fait pas oublier que l'utilisation d'un protocole perso (sur des ports différents) a permis à seafile d'avoir un très bon client de synchro.
Je pense qu'on peut tout critiquer ici mais il faut prendre sans doute un peu de hauteur ;)
[^] # Re: BOF
Posté par bubar🦥 (Mastodon) . Évalué à 6. Dernière modification le 15 décembre 2014 à 21:13.
Ce n'est pas le contenu qui est moinssé, mais son contenant. Une argumentation adroite (et polie) aurait bien mieux fait passer ton idée et ton avis. smartquestions
[^] # Re: BOF
Posté par FantastIX . Évalué à 6.
Si tu expliquais un peu aux mous-du que nous sommes comment tu ferais les choses, on commencerait peut-être à se sentir moins cons, non? (Je parle surtout pour moi, je capte rien dans ce que ça a d'horrifiant d'ouvrir 4 port TCP. Ça doit être pour ça.)
# Synchro HTTP
Posté par flan (site web personnel) . Évalué à 4.
La synchro HTTP est vraiment la bienvenue, ça aidera pas mal quand il est compliqué de faire ouvrir un port supplémentaire. En revanche, je me demande si la synchro HTTP est aussi performante que la version précédente.
Il manque encore l'authentification via HTTP (par exemple en se basant sur un header HTTP, au hasard REMOTE_USER). Ça permettrait d'avoir facilement pas mal de nouvelles méthodes d'authentification comme Kerberos.
[^] # Re: Synchro HTTP
Posté par claudex . Évalué à 3.
Et du SSO.
« 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: Synchro HTTP
Posté par flan (site web personnel) . Évalué à 2. Dernière modification le 14 décembre 2014 à 14:36.
En effet, mais ça dépend de la méthode : faire du SSO avec kerberos est assez facile pour un client lourd, mais les méthodes genre Shibboleth sont nettement plus dures à passer (redirections multiples, utilisation de cookies, javascript, …).
[^] # Re: Synchro HTTP
Posté par halfday . Évalué à -10.
Hey les lumières, "la synchro HTTP est la bienvenue, ça permet de faire plein de chose."
Sans blague ? Je vous ai pas trop entendu pourtant sur mon "BOF" lancé plus haut, qui dénoncait le bind TCP à tout va sur Seafile.
[^] # Re: Synchro HTTP
Posté par flan (site web personnel) . Évalué à 4.
Parce que le HTTP permet beaucoup d'autres choses sans avoir à les recoder dans leur protocole maison, et ça va bien au-delà de binder des ports TCP sur 0.0.0.0 :
mais je me demande toujours ce que ça donne en termes de perfs.
# Streaming de fichier
Posté par elfangor . Évalué à 2.
Je suis en train de regarder Seafile (j'ai actuellement owncloud d'installé chez un hébergeur) pour gérer ma collection de film, série,photo ect…
J'aimerai savoir si il est possible de "streamer" les fichiers directement. J'ai fait les tests avec owncloud en passant par du webdav mais le fichier devait être chargé entièrement avant le début de la lecture (pas très pratique pour un fichier de 1Go).
Est-ce que Seafile propose une solution pour ce genre de cas ?
Peut-être que mon problème de webdav peut-être réglé avec une config de apache, mais je n'ai pas vraiment trouvé de solution à ce niveau.
[^] # Re: Streaming de fichier
Posté par Pulco . Évalué à 1.
Une solution pour les vidéos que je n'ai pas encore essayé :
Bon ok ça n'a rien de trivial, il y a peut-être des solutions plus simple en fonction des besoins.
[^] # Re: Streaming de fichier
Posté par gnumdk (site web personnel) . Évalué à 2.
Euh, avec quoi? Parce que avec nautilus, il monte un dossier webdav et donc je vois pas pourquoi ça fonctionnerait pas sans tout télécharger…
[^] # Re: Streaming de fichier
Posté par elfangor . Évalué à 0.
Le problème que j'ai actuellement avec nautilus et owncloud, c'est que lorsque j'essaye d'ouvrir le fichier, il le télécharge intégralement avec de l'ouvrir, ce qui n'est pas pratique dans le cas d'une vidéo de plus de 100mo.
Mais comme je l'ai dit cela viens peut-être de ma conf apache, mais je n'ai pas vraiment trouvé d'infos à ce niveau.
[^] # Re: Streaming de fichier
Posté par obsidien . Évalué à 2.
En l'état, le streaming ne m'a pas l'air possible en utilisant Seafile. Le support des byte-range requests (nécessaire, sauf erreur de ma part, pour du streaming sur HTTP) était présent dans la roadmap pour la version 4, mais la plupart des fonctionnalités listées ne sont pas présentes dans la version qui est effectivement sortie.
Il y a des chances que l'équipe de dev soit en train de bosser dessus, en tout cas, le problème a déjà été soulevé.
Il y a peut-être une possibilité de contourner le problème en attendant, via Fuse. Je dirai que tu peux monter les fichiers de Seafile dans un dossier de ton serveur via Fuse, et servir ce dossier via Apache, pour avoir le support des byte-range requests.
C'est un domaine que je ne maîtrise pas du tout, donc ce que je dis est à prendre avec des pincettes, n'hésitez pas à me corriger.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.