Seafile en version 4 : nouvelles fonctionnalités au menu

Posté par  . Édité par Benoît Sibaud, ZeroHeure, Nils Ratusznik, tuiu pol et palm123. Modéré par tuiu pol. Licence CC By‑SA.
29
13
déc.
2014
Cloud

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

  • # BOF

    Posté par  . É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  . Évalué à 6.

      Clair, ça obligerait presque à configurer un firewall !

      • [^] # Re: BOF

        Posté par  . É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  (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  . É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  . Évalué à 8.

          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.

          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  . É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  . É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  (site web personnel) . Évalué à 4.

          Bravo les gars au niveau sécu.

          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  . É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  (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  . É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  (site web personnel) . Évalué à 2.

              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 !

              Wai, t'as raison, c'est trop des glands chez SSH, c'est quoi ce port 22 de merde.

          • [^] # Re: BOF

            Posté par  . É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  . É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  (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  . É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  (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  . Évalué à 3.

      Ça permettrait d'avoir facilement pas mal de nouvelles méthodes d'authentification comme Kerberos.

      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  (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  . É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  (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 :

          • nouvelles méthodes d'authentification (Apache ou Nginx permettent beaucoup de choses à ce niveau-là),
          • utilisation de proxy (proxy directs ou reverse proxy),
          • réutilisation de ports déjà ouverts sur les différents firewall,
          • possibilité de faire du MITM pour la sécu…

          mais je me demande toujours ce que ça donne en termes de perfs.

  • # Streaming de fichier

    Posté par  . É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  . Évalué à 1.

      Une solution pour les vidéos que je n'ai pas encore essayé :

      • synchroniser une librairie Seafile contenant les videos via l'API
      • monter une serveur de streaming dans ce genre la : rstream

      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  (site web personnel) . Évalué à 2.

      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).

      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  . É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  . É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.