La société Dropbox a accueilli une nouvelle personne à son conseil d'administration : Condoleezza Rice, conseillère à la sécurité nationale de l'ère Bush et connue pour avoir approuvé des écoutes illégales. Confier ses données à une entreprise requiert une grande confiance et Dropbox vient de perdre la confiance de beaucoup d'utilisateurs. Dropbox s'est empressé d'affirmer que sa stratégie de protection des données reste inchangée.
Si comme beaucoup vous décidez d'abandonner Dropbox, pourquoi ne pas passer à un logiciel libre pour gérer et stocker la mise à disposition de fichiers ? De nombreuses solutions existent, avec serveur ou en peer-to-peer.
Avec serveur
Avec ces solutions, l'idéal est d'avoir son propre serveur. Pour ceux qui n'ont pas l'inclination de maintenir un serveur, des offres d'hébergement payantes et gratuites sont souvent disponibles. Choisissez un hébergeur en lequel vous avez confiance, dans un pays respectueux de vos libertés. Une fois que le serveur est en place, il suffit de s'y connecter avec le logiciel client.
- Owncloud, qui requiert un serveur OwnCloud. Nombreuses offres d'hébergements à travers toute l'Europe. Beaucoup de fonctionnalités annexes, ce qui peut être un inconvénient. GNU-AGPLv3 pour le serveur, GNU-GPLv3 pour Linux/Windows/Mac/Android, licence MIT pour iOS.
- Seafile, qui requiert un serveur dédié. GNU-GPLv3. Linux/Windows/Mac/Android/iOS.
- Pydio (anciennement Ajaxplorer), qui est écrit en Javascript et PHP. Nécessite un serveur Web quelconque avec PHP5 dont les extensions MCrypt et GD. Simple à mettre en place. C'est un projet qui semble dynamique, plutôt ergonomique. GNU-AGPL. Linux/Windows/Mac.
- SparkleShare, qui requiert un serveur Git. Idéal avec de petits fichiers, notamment pour les grandes équipes qui veulent un historique complet. GNU-GPLv3. Linux/Mac/Windows.
- git-annex assistant, aussi basé aussi sur Git mais mieux équipé pour les gros fichiers. GNU-GPLv3. Linux/Windows/Mac/Android. Ne nécessite pas forcément de serveur central.
- Syncany, qui requiert un serveur FTP ou WebDAV. GNU-GPLv2. Linux/Windows/Mac.
- CmisSync, qui requiert un serveur de GED. Adapté aux entreprises qui disposent déjà d'un serveur Alfresco, Nuxeo, SharePoint ou autre. GNU-GPLv3. Linux/Windows/Mac.
- Unison, qui nécessite une configuration en étoile, avec un "hub" au centre. Unison a l'avantage d'exister depuis longtemps, mais il souffre d'une certaine vétusté, il est difficile à mettre en place pour un utilisateur lambda et son code source en OCaml n'attire pas foule de développeurs. GNU-GPLv3. Linux/Windows/Mac.
- NdM : On nous signale Cozy dans les commentaires. En plus du gestionnaire de fichiers, ce cloud perso s'accompagne d'autres applications comme un carnet de contacts, un calendrier, un lecteur de flux RSS…
En peer-to-peer
Si votre smartphone est allumé la plupart du temps, vous n'avez pas vraiment besoin d'un serveur. Le logiciel non-libre BitTorrent Sync l'a compris et connait actuellement un succès phénoménal qui lui vaut le surnom de Dropbox-killer. Des solutions Open Source existent aussi, pour l'instant loin de rivaliser (en particulier, pas d'application pour smartphone).
Le principe est de créer un "secret" sur l'appareil contient le répertoire à partager, puis renseigner ce secret sur chaque appareil à connecter.
- Tahoe-LAFS est volontairement axé sur la sécurité des données, non seulement du point de vue de la disponibilité (en faisant en sorte que vos données soient suffisamment réparties), mais également du point de vue de la confidentialité (tout est chiffré, seules les personnes qui obtiennent un lien direct ont accès aux données en clair). L'organisation d'un groupe de pairs se fait typiquement sur les relations de confiance entre plusieurs humains qui veulent collaborer ensemble. GNU-GPLv2. Linux.
- syncthing dont le but affiché est d'être un équivalent Open Source de BitTorrent Sync, codé en Go. Comme BitTorrent Sync, le client est une interface web locale. Licence MIT. Linux/Windows/Mac.
- ClearSkies, la même chose en C++. GNU-LGPLv3. Seulement au stade de prototype, client basique en Python.
- Hive2Hive qui se concentre pour l'instant sur sa bibliothèque. Licence MIT. Pas de client.
# Et Cozy !
Posté par gelnior (site web personnel) . Évalué à 6. Dernière modification le 23 avril 2014 à 16:00.
Et n'oubliez pas le petit français Cozy ! http://cozy.io. En plus du gestionnaire de fichiers, ce cloud perso s'accompagne d'autres applications comme un carnet de contacts, un calendrier, un lecteur de flux RSS…
[^] # Re: Et Cozy !
Posté par Sytoka Modon (site web personnel) . Évalué à 4. Dernière modification le 23 avril 2014 à 16:01.
http://cozy.io/ NdM: corrigé dans le commentaire précédent
[^] # Re: Et Cozy !
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
J'en ai profité pour l'ajouter dans la news.
[^] # Re: Et Cozy !
Posté par Nicolas Raoul (site web personnel) . Évalué à 4.
Le site web de Cozy ne parle pas de synchronisation de fichiers. Dans la démo je viens une app appelée "files", mais pas de client desktop à l'horizon. Est-ce une fonctionnalité cachée ? Ou Cozy est juste un serveur, sur lequel je peux installer un des outils mentionnées dans la dépêche ci-dessus ?
[^] # Re: Et Cozy !
Posté par daeavelwyn . Évalué à 3. Dernière modification le 24 avril 2014 à 12:10.
visiblement, le client desktop devait arriver pour février, mais je n'ai pas trouver non plus d'infos sur une quelconque release :
https://groups.google.com/forum/?fromgroups#!searchin/cozy-cloud/cozy$20desktop$20client/cozy-cloud/wx6PvJbb9t0/r3XQV21IC9YJ
Mais il semble que tu puisses le configurer avec n'importe quel client qui supporte webdav
[^] # Re: Et Cozy !
Posté par gelnior (site web personnel) . Évalué à 3. Dernière modification le 24 avril 2014 à 18:35.
Effectivement les choses ont pris pas mal de retard. On devait le faire pour un client mais il nous a demandé pas mal de développements spécifiques. Du coup la version que nous avons n'est pas publiable. Le projet se terminant on a repris les choses du côté des clients Linux/MacOSX et Android.
# chiffrement
Posté par Adrien . Évalué à 10.
Pour ceux qui sont tenté par « l'externalisation des données », on peut aussi conseiller très très fortement le chiffrement des données, notamment en entreprise. Des conteneurs TrueCrypt, GPG ou autres sont à recommander.
[^] # Re: chiffrement
Posté par nomorsad . Évalué à 6.
Encfs pour moi!
[^] # Re: chiffrement
Posté par boubou (site web personnel) . Évalué à 2.
Ou pour être plus efficace, d'utiliser une solution qui crypte sur le client directement donc seafile ou sparkleshare (de façon native) ou git-annex avec une remote de type gcrypt (http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/). Syncany fait ça aussi, mais à mon avis, ce n'est pas assez stable. En outre le choix de ne pas utiliser de serveur rend le design fragile (en terme de système réparti c'est un vrai challenge de réussir une exclusion avec un stockage idiot comme unique support).
# Owncloud, Seafile et Tahoe-LAFS
Posté par SaintGermain . Évalué à 10.
Personnellement je suis utilisateur de Dropbox et j'avais cerné mes besoins ainsi :
Le cas d'utilisation typique c'est la fête de famille où tout le monde souhaite s'échanger et regarder les photos.
Voici mon léger retour d'expérience sur quelques solutions:
Vraiment il faut reconnaître à Dropbox d'avoir réussi à rendre très accessible une technologie pas vraiment évidente. J'aide dans la mesure de mes moyens, mais les solutions libres ont du chemin à faire pour le rattraper !
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Gof (site web personnel) . Évalué à 3.
Si le problème comparé à dropbox est la gestion du serveur, dans ce cas il faut opté pour les offre d'hébergement de owncloud qui gerre le serveur pour toi. Il fallait suivre le liens dans la dépêche vers http://owncloud.org/providers/
Là encore on remets ses données dans les main d'une tierce entreprise. Mais au moins les logiciels (client, serveur) sont libres et les protocols sont ouverts.
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par SaintGermain . Évalué à 5.
Administrer Owncloud était relativement simple (la complexité c'était avec Seafile). C'est les bogues rencontrés (en tant qu'administrateur ou utilisateur) qui m'ont plutôt gêné.
[mavie]
J'ai rencontré pas mal de soucis mais d'autres avaient déjà remonté l'erreur. Ayant testé la version 3, 4 et 5, j'avais l'impression d'une priorité donnée aux fonctionnalités et à l'interface plutôt qu'à la stabilité. Il y a eu d'ailleurs un message sur la liste de diffusion qui m'avait marqué : Regarding quality. J'ai laissé de côté (faute de temps) après avoir vu plusieurs messages de suite de personnes ayant de gros problème de mise à jour entre la version 4 et la version 5 :
Upgraded to Owncloud 5. Here come the conflict files again
upgrade from 4.5 to 5.0 lost all files
[/mavie]
Après que les choses soient claires : c'est du logiciel libre et c'est déjà très bien qu'il existe et qu'il évolue. Je crois suffisamment au projet pour y avoir investi un peu de temps et je pense peut être y retourner un jour.
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par claudex . Évalué à 6.
Oui, Owncloud supporte officiellement pgsql mais en fait, tu te retrouve avec pleins de bug à chaque migration. En fait, il ne tourne bien qu'avec Mysql.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par woprandi . Évalué à 0.
Je comprends pas pourquoi MySQL semble si souvent privilégié à PostgreSQL dans divers projets alors que la supériorité du dernier n'est plus à démontrer…
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par claudex . Évalué à 5.
Parce que Mysql est partout. Trouver un hébergement avec MySQL ne pose pas de problème, en trouver avec un pgsql, ça devient plus compliqué. Et comme c'est comme ça depuis quelques temps, ça fait effet boule de neige, les hébergeurs ne proposent plus que MySQL parce que les softs le prennent en charge, voire ne gère que ça. Et les soft le prennent en charge, voire ne gèrent que ça parce que les hébergeurs ne proposent que ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par barmic . Évalué à 3.
Ça m'a l'aire d'être de moins en moins le cas. On a de plus en plus d'hébergement qui s'éloignent du poussiéreux LAMP. Free propose postgresql, les clouds proposent des solutions de stockage NoSQL la majorité du temps et les solutions du type serveurs dédiés sont de plus en plus démocratiser.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par claudex . Évalué à 3.
J'ai plus l'impression que les gens s'éloignent des hébergeurs pour se tourner vers Facebook/Dropbox/Youtube/… Et donc, en proportion, on voit plus de truc pour power user qui étaient là avant quand même, juste moins utilisé en proportion.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par barmic . Évalué à 4.
Les machins clouds sont relativement récents (GAE, EC2, etc). Ce qu'il faut c'est voir qui va installer ces solutions et sur quoi ils vont le faire. Aujourd'hui tu as largement plus de choix qu'il y a 5 ans pour faire autre chose que du LAMP. Les hébergeurs de contenus n'ont rien avoir avec ce dont on parle.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Argon . Évalué à 3.
Personnellement j'avais trouvé ownCloud assez lent (en web) et peu fiable en synchronisation mais avec la version 6 ça marche vraiment très bien. Actuellement j'ai un vps OVH classic 1 sur une Debian avec Owncloud 6 et Ampache, ça tourne au poil pour de la synchro fichier (2 PC Linux + 1 Android) et de la synchro calendrier/contact sur Evolution/Android. Je me suis débarrassé de la grosse partie Google sur mon Android, j'ai juste laissé le compte pour Google Play (seul synchro active).
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par BAud (site web personnel) . Évalué à 1.
et donc, tu vas aussi évoluer concernant ampache ?
cf. http://linuxfr.org/news/ampache-doped-ampache-part-en-fourchette
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Argon . Évalué à 1.
En fait j'avais vu la news avant et je suis effectivement sur Ampache Doped ;)
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par BAud (site web personnel) . Évalué à 1.
ah bah, tu as eu raison, en plus je viens de voir : https://linuxfr.org/users/nicolas_raoul/journaux/deux-mois-apres-le-fork-d-ampache-fusionne-avec-l-original
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Le Gab . Évalué à 1.
Tu pourrais aussi t'en débarrasser, il y a script dispo qui permet de télécharger les APK, fait par un gars passant aussi par ici, j'ai oublié le nom, désolé.
Il te faudra toujours un compte google mais tu pourrais en faire un non-officiel.
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Wawet76 . Évalué à 1.
Si sur son téléphone il n'utilise un compte Google que pour Play, il peut tout aussi bien en utiliser un "non officiel" directement.
Ou alors je n'ai pas compris ce que tu veux dire.
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Argon . Évalué à 1.
Je ne comprend pas l'intérêt d'utiliser cette application si je dois utiliser un autre compte Google ? Ou alors il y a quelque chose qui m'échappe :)
Bon de toute façon j'ai commencé à tester ownCloud et autre (caldav, carddav) pour pouvoir switcher d'içi quelques temps de Android vers jolla ;)
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Le Gab . Évalué à 0.
ne pas avoir l'identifiant de ton tel associé à ce compte, vu que ce dernier est deja associé à ton compte original.
bref. limiter/stopper l'empreinte que tu laisses chez google
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Argon . Évalué à 0.
En fait je n'ai plus rien sur mon compte Google/Gmail et autre, il reste juste le spam :)
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Nicolas Raoul (site web personnel) . Évalué à 1.
Moi je vois un intérêt énorme, c'est de ne pas avoir à installer l'application Google Play elle-même.
Le principal défi pour le futur d'Android en tant qu'écosystème libre est de réussir à éviter Google Play Services, la grosse boite noire propriétaire (et non-redistribuable) qui malheureusement prend de plus en plus de place dans Android, sous la pression de Google. Je vois deux stratégies possibles:
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par Sufflope (site web personnel) . Évalué à 2.
Malheureusement elle ne fonctionne pas pour télécharger les APK payants (même si on a renseigné son compte google perso au lieu de celui par défaut, et qu'on a acheté l'app via le store web). Du moins quand j'ai essayé en décembre.
[^] # Re: Owncloud, Seafile et Tahoe-LAFS
Posté par rakoo (site web personnel) . Évalué à 3. Dernière modification le 24 avril 2014 à 15:11.
Je pense que c'est vrai, mais en plus d’être distribué et chiffré c'est quand même super simple pour le partage.
Par défaut tout ce que tu mets dans Tahoe-LAFS est immuable; lorsque tu donnes la référence d'un fichier a quelqu'un, tu lui donnes une identité immuable. Il peut uploader une autre version mais elle aura une autre identité et il faudra alors convaincre les autres que sa version est la bonne.
Les dossiers sont (en général) mutables, c'est-a-dire que tu peux modifier leur contenu et garder la même identité. Cette identité mutable est basée sur une bête paire de clés asymétriques (RSA pour le moment). Lorsque tu as créé le dossier tu as 2 identités: une qui contient la clé privée et une qui ne la contient pas. Tu peux choisir de donner la première, et tout ceux qui ont cette référence pourront modifier la valeur pointée par cette référence (puisqu'ils ont la clé privée), ou tu peux donner la deuxième, que les autres pourront seulement lire.
Et tout ça se fait de manière transparente pour l'utilisateur: tout ce qu'il voit c'est une URI qui peut pointer sur n'importe lequel des nœuds qui servent du HTTP.
Ah et en plus de ça, pour l'installation, tu galères peut-être un peu (ou pas) pour installer les dépendances python, mais après ça marche nickel.
# Quid de la robustesse de ces solutions ?
Posté par dinomasque . Évalué à 7.
Mon modeste point de vue est assez peu engageant :
- Dropbox est fiable, pas super accessible (bloqué par pas mal de proxies) et douteux du point de vue de la confidentialité
- Digiposte est fiable, top sur la confidentialité, mais très peu accessible (nécessité de passer par le site web ou une appli smartphone)
- Owncloud et compagnie ont la réputation (sur Linuxfr) d'être peu fiables (fichiers perdus ou non synchronisés), assez accessibles, et diversement sécurisés (ça dépend beaucoup du professionnalisme de l'administrateur du serveur)
Existe-t-il un comparatif de ces outils sur la base de mesures de leur fiabilité, de leur disponibilité/accessibilité et de leur confidentialité en conditions réelles ?
BeOS le faisait il y a 20 ans !
[^] # Re: Quid de la robustesse de ces solutions ?
Posté par Sytoka Modon (site web personnel) . Évalué à 6.
SpiderOak : fiable et sécurisé : https://spideroak.com/
http://en.wikipedia.org/wiki/SpiderOak
A priori, le client Mobile est libre. Le client Linux est principalement en Python. A noter que le chiffrement a lieu sur le poste client.
[^] # Re: Quid de la robustesse de ces solutions ?
Posté par Argon . Évalué à 1.
J'avais testé SpiderOak il y a quelque temps, mais c'était abominablement lent en synchronisation.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
# Camlistore
Posté par Bruce Le Nain (site web personnel) . Évalué à 7.
Je ne sais pas si le développement est actif ou pas, mais il y a aussi http://camlistore.org/
[^] # Re: Camlistore
Posté par kodijak . Évalué à 2.
Le développement est de plus en plus actif oui.
Pour l'instant c'est surtout de la ligne de commande pour Linux, Windows et Mac OSX et des clients Android et iOS sont disponibles dans les sources du projet.
# syncthing
Posté par i M@N (site web personnel) . Évalué à 5.
Je découvre Syncthing et je suis en train de tester, c'est génial!
Excellente dépêche, merci.
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: syncthing
Posté par Larry Cow . Évalué à 6.
C'est pas mal, et ça ressemble pas mal à Teapotnet (qui ne bouge plus beaucoup?), mais avec un gros bémol : Teapotnet était capable de mettre en relation N*N des machines cachées chacune derrière un NAT, dès lors que l'une d'entre elles était accessible par tout le monde. Ici, deux machines ne peuvent se parler que si au moins une d'entre elles est accessible (i.e. via PortForward ou uPNP). Dommage, même si ça semble évoluer vite.
[^] # Re: syncthing
Posté par i M@N (site web personnel) . Évalué à 2.
Assez déçu après 2 jours de test je ne suis pas convaincu.
Je vais attendre que ça évolue, trop d'erreurs de synchronisation comme avec BitTorrent Sync.
Les liens symboliques n'ont pas l'air d'être pris en compte d'ailleurs.
La doc est trop succincte et pas moyen de savoir ce qui se passe quand des fichiers qui devraient être synchronisés ne le sont pas.
Dommage, les dossiers ~/Sync avaient l'air de bien fonctionner mais quand j'ai voulu ajouter un dossier maître sur une machine en read-only et à tenter de le synchroniser avec un autre sur une seconde machine celle-ci ne voyait pas la moitié des fichiers ou dossiers à synchroniser.
Je vais garder ma méthode à base de rsync qui a l'avantage d'être très fiable.
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: syncthing
Posté par rewind (Mastodon) . Évalué à 2.
J'ai regardé un peu le protocole et ça m'a l'air assez clean. Tu penses que ça vient de l'implémentation ? D'après le bug tracker, il y a pas mal de problèmes.
[^] # Re: syncthing
Posté par i M@N (site web personnel) . Évalué à 1.
Je ne sais pas d'où ça vient, je ne connais pas le Go.
La seule chose que je peux dire c'est qu'à l'usage ce n'est pas fiable pour le moment.
Beaucoup de bugs et beaucoup ont été corrigés.
J'espère qu'une prochaine version sera utilisable, ils en sont encore à une v0.8.1.
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: syncthing
Posté par Gwen311 . Évalué à 1.
Pour info, les devs de Teapotnet bossent sur une mise à jour majeure (en particulier, je crois qu'ils réécrivent une grosse partie du système de chiffrement). Voir pour des précisions la branche crypto du git :
https://github.com/paullouisageneau/Teapotnet
# Seafile
Posté par Tof . Évalué à 6.
J'utilise seafile depuis plus d'un an, et il marche farpaitement bien.
L'installation est vraiment aisée (mais pas très standard).
Et le projet semble bien vivant, plusieurs versions sont sorties dans l'année; sans aucun souci pour l'upgrade, à chaque fois.
Juste avant j'avais utilisé owncloud, et eu des soucis en masse avec la synchro. Même s'il paraît que "ça va mieux maintenant", j'ai été refroidi.
Du coup, bah, je recommande Seafile.
[^] # Re: Seafile
Posté par Astaoth . Évalué à 2.
Il a l'air efficace et fiable, j'ai hésité à me lancer dans sa mise en place chez moi. Finalement je ne l'ai pas fait parce qu'il n'est pas directement compatible avec FreeBSD, et je ne me sentais pas trop de m'amuser avec l'émulation de Gnu/Linux pour un outil manipulant mes données.
Emacs le fait depuis 30 ans.
[^] # Re: Seafile
Posté par SaintGermain . Évalué à 1.
De mémoire j'avais testé Seafile en partant de ce guide : Deploying Seafile with nginx and MySQL on Debian Wheezy
Et j'avais adapté à l'aide de ces deux pages :
J'avais trouvé à l'époque toute la procédure vraiment très compliquée et qu'il était facile de faire des erreurs :
Seafile + Debian Squeeze + MySQL + Apache + non-root domain
Je n'ai vu que des avis positifs sur Seafile, donc je vais peut-être me retrousser les manches et tenter de nouveau l'aventure !
[^] # Re: Seafile
Posté par Jean-Max Reymond (site web personnel) . Évalué à 3.
J'ai installé Seafile, il y a deux mois suite à des avis positifs sur Linuxfr et que du bonheur. Une dizaine de personnes sous WIndows et Linux qui synchronisent en permanence et aucun soucis, niveau de service idem à Ubuntu One.
[^] # Re: Seafile
Posté par realitix (site web personnel) . Évalué à 3.
Idem pour moi, Seafile sur un raspberry cela marche du tonnerre!
[^] # Re: Seafile
Posté par ze_farf . Évalué à 2.
Idem, je n'ai que d'excellents retours à faire concernant Seafile (nginx+mariadb), je viens d'ailleurs tout juste de mettre à jour mon serveur avec la version 3.0 sortie hier. Simple, efficace, zéro problème. Il manque juste l'auto-upload des photos depuis un mobile Android, point qui a malheureusement été décalé dans la roadmap à la v4.
Je suis parti de owncloud qui semblait initialement répondre à mes besoins mais que je trouvais lent, lourd à administrer, buggé et ce quel que soit les versions. (stable, nightly build, bêta en version 5 et 6)
Je n'ai que de supers retours avec les diverses personnes (GNU/linux et windows) qui l'utilisent. Bref, au top pour mes besoins.
[^] # Re: Seafile
Posté par SaintGermain . Évalué à 2.
Damned c'est vraiment un concert d'éloges pour Seafile, il faut que j'essaye de nouveau.
Je suis vraiment le seul à avoir galéré pour l'installation du serveur ?
C'est mon égo qui en prend un coup… ;-)
[^] # Re: Seafile
Posté par daeavelwyn . Évalué à 1.
Mouai..enfin là, après trois heures à patauger, je renonce, c'est déjà super pas évident à configurer sans SSL, mais alors si en plus je tente de rajouter du chiffrement pour l'accès web, c'est juste la misère ! Dommage, ça à l'air top comme projet, mais c'est carrément trop le bronx à mettre en oeuvre pour mes modestes compétences….et j'ose même pas imaginer les upgrades :-(
[^] # Re: Seafile
Posté par flan (site web personnel) . Évalué à 2.
Quand j'installe un service web chez moi, j'aime bien que l'authentification soit gérée par le serveur web (apache ou nginx) et non par l'application.
Ça me permet d'utiliser ce que je veux pour l'authentification, en évitant les bêtes mots de passe.
est-ce faisable pour seafile ?
J'ai l'impression que oui, vu que ça me semble basé sur Django, mais j'aurais aimé être sûr :)
[^] # Re: Seafile
Posté par realitix (site web personnel) . Évalué à 3.
J'utilise nginx devant seafile et j'ai une authentification HTTP en SSL géré par nginx.
Donc oui c'est possible et tout est bien expliqué dans le wiki de Seafile vraiment bien fait.
# Git-annex a-t-il vraiment besoin d'un serveur ?
Posté par Gastlag . Évalué à 4.
Je ne pense pas qu'on puisse dire que Git-annex a vraiment besoin d'un serveur pour faire de l'échange de fichier, c'est uniquement nécessaire si l'on souhaite faire de l'échange de fichier sans que les personnes soient connectées en même temps.
D'ailleurs, pour ceux qui ne se sentent pas de gérer leur propre serveur, Rsync.net offre une réduction sur ses offres d'hébergement spécifiquement pour les utilisateurs de Git-annex : http://www.rsync.net/products/git-annex-pricing.html
Il est aussi possible d'utiliser Tahoe-LAFS comme outil d'hébergement/sauvegarde avec Git-annex :
http://git-annex.branchable.com/special_remotes/tahoe/
Actuellement il y a des réflexions pour utiliser Bittorrent ou telhash :
http://git-annex.branchable.com/todo/Bittorrent-like_features/
http://git-annex.branchable.com/forum/Wishlist:_Bittorrent-like_transfers/
https://git-annex.branchable.com/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/
http://git-annex.branchable.com/design/assistant/telehash/
Sinon Joey Hess a aussi travaillé à simplifier la production d'external special remotes ad-hoc en développant un protocole spécifique :
http://git-annex.branchable.com/special_remotes/external/
[^] # Re: Git-annex a-t-il vraiment besoin d'un serveur ?
Posté par Anonyme . Évalué à 2.
Effectivement, pas besoin de serveur pour utiliser git-annex. Moi je l'utilise pour stocker mes données sur des disques USB, avec pour les données importantes une copie sur au moins 2 disques, sans utiliser de serveur.
# Journees du CNRS sur ces thematiques
Posté par sylvain Maurin (site web personnel) . Évalué à 6.
Des informaticiens du CNRS organisent des journees thematiques. Cette annee le cloud est a l'honneur.
Il y a deja eu 2 presentations seafile et owncloud, elles sont accessibles a l'adresse :
http://aramis.resinfo.org/wiki/doku.php?id=pleniaires:pleniere17avril2014
Une autre journee rediffusee en webcast devrait bientot avoir lieu avec une autre presentation de owncloud :
http://www.resinfo.cnrs.fr/spip.php?article60
# dropbox devrait s'appeller dropbomb à présent
Posté par Le Gab . Évalué à -5.
c'est tout.
# bsync
Posté par Marc Maurice (site web personnel) . Évalué à 5.
J'ai codé une alternative à Unison il y a quelques mois de cela. Très pratique.
https://github.com/dooblem/bsync
[^] # Re: bsync
Posté par SaintGermain . Évalué à 2.
Ton logiciel a l'air vraiment très intéressant, cela vaudrait le coup d'en faire au moins un journal (voire une dépêche !).
Je n'ai pas très bien compris comment tu détectais les fichiers déplacés (il faut que je me renseigne sur ces histoires d'inodes).
[^] # Re: bsync
Posté par Marc Maurice (site web personnel) . Évalué à 1.
Merci ;) tu as raison, je vais essayer d'en faire un journal.
Le numéro d'inode identifie de manière unique un fichier sur un système de fichiers Linux. Si je déplace ou renomme un fichier, ce numéro reste le même, mais son chemin change.
[^] # Re: bsync
Posté par SaintGermain . Évalué à 1.
Ah ok donc tu fais comme Unison je suppose et tu gardes une liste des inodes quelque part ?
Enfin bon le plus simple pour comprendre est quand même que je teste.
Merci
[^] # Re: bsync
Posté par Le Gab . Évalué à 1.
Tu devrais changer les termes dans tes exemples, plutôt que
tu devrais écrire dans ton message d'aide en ligne et sur ta page github explicative
Ça semble logique mais malgré toutes ces années avec des commandes comme tar, cpio, rsync (avec slash ou sans slash) je ne suis jamais sûr.
À la limite, tu gardes ce côté implicite et tu proposes la possibilité de les spécifier de manière explicite avec des options du type
Je suis d'accord pour que l'ordi fasse le plus possible le boulot à notre place mais franchement, quand il s'agit synchronisation de fichier, je préfère être sûr de ce que je fais.
[^] # Re: bsync
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
J'ai compris que c'est comme unison donc il n'y a pas de source / destination. Il s'agit de faire la fusion (ou non, au choix) des deux arborescences…
[^] # Re: bsync
Posté par Le Gab . Évalué à 1.
Comment ça se passe en cas de fichier(s) effacé(s)? Et même dans le cas d'un effacement par erreur? Est-ce restaurable? Un peu à la manière de DropBox, j'ai bizarrement découvert ça récemment.
En fait, je me rend compte que ma confusion viendrait peut-être d'essayer d'utiliser un tel logiciel en l'assimilant à un logiciel de sauvegarde.
[^] # Re: bsync
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Dans unison, tu as chaque dossier dans deux colonnes et des flèches au centre soit vers la droite, soit vers la gauche…. Tu acceptes, modifies comme tu veux et lance (go) la synchro…
Il y a des options pour y aller en automatique et laisser le soft faire le meilleur choix avec ce qu'il est capable de savoir. Il ne pourra jamais savoir que tu as fait une erreur…
Bref, c'est de la synchro bi-directionnelle, pas du backup.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.