Sommaire
- Le contexte: centralisation, décentralisation, et distribution.
- Le partage / synchronisation de fichiers
- Et vous ?
Le contexte: centralisation, décentralisation, et distribution.
Je suis depuis très longtemps sensible aux potentielles aliénations numériques que je perçois. Afin d'y apporter des solutions concrètes, autant que pour apprendre, je m'auto-héberge d'ailleurs depuis plusieurs années (mail, cloud, messagerie instantanée, VPN, etc.).
Jusqu'ici j'ai plutôt fait la promotion de la décentralisation. Je réalise cependant que sa principale limite est de ne pas s'attaquer à la dépendance vis-à-vis d'un "centre". Ce centre, c'est un serveur ou d'un service qu'il s'agit d'héberger et de maintenir, avec toute la charge de travail spécifique que cela entraine. Il est possible d'assumer soi-même cette charge lorsqu'on est curieux, débrouillard et qu'on y consacre le temps nécessaire, mais pour le commun des mortels, il devient nécessaire de déléguer à un tiers, que ce soit par exemple Google pour ses services ou OVH pour son hébergement. Au passage, les uns et les autres méritent évidemment d'être rétribués pour ce travail qu'ils fournissent, qu'ils facturent ou qu'ils profitent de nos données personnelles.
En parallèle de ce constat sur les limites de la décentralisation, j'ai pu comme vous voir l'émergence progressive de solutions distribuées plus ou moins équivalentes en terme de fonctionnalités à celles, décentralisées, que j'ai mises en place dans le cadre de mon auto-hébergement. J'envisage donc d'explorer les possibilités de remplacement de mes services décentralisés par des solutions distribuées là où c'est possible, et de vous faire un compte-rendu ici de temps en temps.
Le premier épisode sera lié au besoin de partage/synchronisation de fichiers. Si ce journal reçoit un accueil favorable, je pourrais reprendre le clavier concernant la messagerie instantanée (remplacement d'un serveur XMPP), l'aide à distance (remplacement d'un VPN).
Le partage / synchronisation de fichiers
Mon premier besoin est simple et je crois que nous sommes beaucoup à le partager ici: il s'agit de pouvoir synchroniser et partager des contenus entre plusieurs machines (y compris un téléphone Android).
Le partage/synchronisation de fichiers peut se faire via un service centralisé comme Google Drive ou Dropbox, un serveur décentralisé et libre comme ownCloud ou Seafile, ou sans serveur du tout par Bittorrent Sync par exmple, ou en l'occurrence plutôt Syncthing qui a l'avantage d'être libre.
Il y a 4 ans, j'avais choisi ownCloud. Je me pose aujourd'hui la question de lui renouveler ma confiance. J'en suis très content, mais l'administration du serveur m'agace un peu. De plus, j'ai été confronté à un problème de mise à jour de la version 8.2.2 vers la version 9.0.0 - sans doute lié à ma configuration atypique, je ne blâme pas ownCloud lui-même, n'empêche que ça coince et que je suis lassé de devoir décoincer.
J'ai donc installé Syncthing en test, et voilà mes impressions après deux semaines.
Installation de Syncthing
Syncthing s'installe très facilement, y compris sur Android. Le binaire peut être lancé à la main ou en tant que service au démarrage de la machine. Par défaut, il ne propose qu'une interface web, rapide et très claire. Il faut donc se tourner vers un programme annexe avoir une icône dans le systray, comme Syncthing-gtk ou QSyncthingTray. À noter que Syncthing vérifie régulièrement si les répertoires partagés ont changé. L'installation de syncthing-inotify permet de déclencher automatiquement les synchronisations. C'est plus efficace et plus propre.
Configuration
Des machines, des répertoires
Pour chaque machine, elle se fait en deux étapes: il faut déclarer auprès d'elle les autres machines avec lesquelles des répertoires vont être partagés, et ces répertoires eux-mêmes. Avec Syncthing: pas de nom d'utilisateur, pas de mot de passe, tout passe par des clés, des hashs, et des QR codes très pratiques. Tout juste marche.
Contrairement à la plupart des outils de synchronisation qui ne permettent de partager qu'un seul répertoire dans lequel il faudra déposer les fichiers à synchroniser/partager, Syncthing peut gérer un nombre arbitraire de répertoires où qu'ils soient. C'est idéal pour partager le répertoire CAMERA d'un smartphone avec un ordinateur, afin de s'éviter l'étape pénible de récupération de photos, tout en synchronisant également un autre répertoire pour envoyer des mp3 sur le téléphone à partir du moment où ils sont déposés au bon endroit sur l'ordinateur.
Attention à la toile d'araignée !
Cette flexibilité de Syncthing le rend aussi potentiellement plus complexe. La configuration d'un partage entre deux machines est simple et intuitive et, emporté par l'élan, on peut rapidement se retrouver à chercher à synchroniser une foultitude de répertoires entre 4, 5, voire encore davantage de machines. Au final Syncthing s'en sortira sans doute très bien, mais vous nettement moins.
Pseudo synchronisation asynchrone
Comme la synchronisation se fait directement en pair-à-pair, seuls les pairs connectés à un instant donné se synchronisent entre eux. Autrement dit, une modification faite sur une machine A qui est ensuite éteinte ne sera pas propagée à une machine B qui viendrait de s'allumer. Une solution simple consiste à partager le répertoire également avec une machine C qui reste allumée entre temps, pour recevoir ce qui doit être synchronisé avant l'extinction de A, puis pour le propager jusqu'à B. Si vous avez des Pi qui traînent…
Utilisation
À l'utilisation, Syncthing juste marche, même s'il y a parfois une latence dans l'établissement de la connexion avec les autres machines. Une fois établie, la synchronisation est bien plus efficace que celle de ownCloud car contrairement à ce dernier qui transfert en intégralité tout fichier modifié, Syncthing ne transfert (presque) que les changements, (presque) comme rsync. C'est particulièrement efficace pour le partage d'images-disques de machines virtuelles par exemple. Il est également possible de conserver des copies des fichiers modifiés ou supprimés (de moult façons), ou de s'assurer qu'un répertoire ne sera partagé qu'en lecture seule par exemple.
Note: sans "serveur", sans "service", Syncthing n'a pas de centre. Son utilisateur confie donc des données à "quelque chose" qui n'a pas de centre. C'est à la fois magique et déstabilisant: sans "centre", aucune autorité à laquelle réclamer ses données en cas de problème. Je ne peux qu'imaginer ce que pourraient donner les évolutions de la famille de la blockchain, par exemple.
Comparaison avec ownCloud
Depuis le début du journal, j'oscille entre synchronisation et partage, entre fichiers/répertoires et contenus. En réalité, Syncthing et ownCloud ne sont pas des équivalents. D'ailleurs, certains d'entre vous ont peut-être tiqué lorsque j'ai parlé de remplacer l'un par l'autre.
Syncthing fait de la synchronisation de répertoires entre des machines. OwnCloud fait la même chose, quoiqu'à mon sens moins bien, mais y ajoute également le partage de contenus au sens large (y compris contacts et agendas par exemple) entre utilisateurs, créant ainsi un contexte collaboratif extensible par fédération.
En effet, contrairement à Syncthing, ownCloud permet de gérer finement des permissions contenu par contenu, et met à disposition une interface web pour accéder aux contenus partagés, que le destinataire ait ou pas un compte sur une instance d'ownCloud. Pour partager un répertoire via Syncthing, il faut que le destinataire l'ait également installé. Compliqué.
OwnCloud dispose d'une foultitude d'extensions de plus ou moins bonne qualité, par exemple pour s'intégrer à un LDAP existant. À travers ces dernières, il propose beaucoup de fonctionnalités qui sont essentielles dans un environnement collaboratif, c'est à dire orientées "usage", alors que Syncthing est orienté fichiers et répertoires. Ces fonctionnalités supplémentaires de ownCloud impliquent une complexité (voire une complication) qui ne fait pas nécessairement de sens pour un utilisateur individuel. Ce dernier pourrait se retrouver bien davantage dans un projet comme Syncthing.
Avec Syncthing, il n'y a aucune instance centrale à administrer et à sauvegarder. La sécurité - en tout cas en terme de confidentialité - inspire nettement plus confiance que celle de ownCloud, qui hérite de fondamentaux compliqués (PHP, toussa). Syncthing me semble plus sûr, plus résilient. Il ne fait qu'une seule chose et pour autant que je puisse en juger, il la fait bien.
Au final
Au final, les cas d'utilisation de Syncthing et d'ownCloud sont donc bien différents. Pour mon usage, les avantages de Syncthing dépassent ses limitations. Pour partager des fichiers, je passerai sans doute par Framadrop par exemple, à moins que je mette en place un serveur web statique pour servir un répertoire synchronisé par Syncthing.
Les possibilités sont multiples.
La seule chose qui me chagrine, c'est de devoir encore me reposer sur ownCloud pour gérer contacts et calendriers. Pour l'instant j'hésite entre Baïkal, Radicale, Davical et SabreDav. Peut-être avez-vous des conseils à donner ?
Et vous ?
Et vous alors ?
Plutôt ownCloud ou Syncthing ou équivalent ?
Plutôt centralisé, décentralisé, ou distribué ?
Pour quelles raisons ?
La suite ? Oui ? Non ?
Aurel.
# Pour la suite…
Posté par NiKaro (site web personnel) . Évalué à 10.
Journal intéressant, pour la suite ce sera donc un… oui ! :-)
Ça m'intéresse de savoir ce que tu vas proposer pour l'aide à distance.
# *Dav
Posté par Mimoza . Évalué à 6.
Pour avoir un peu regarder la chose il y a une grosse différence entre Davical (historique) et Radical (a le vent en poupe). Le premier essayer de coller le mieux à la norme alors que le second de fonctionner avec des clients bien précis. Donc a toi de voir si tu vas avoir des client qui sorte de ceux supporter par Radical, Davical est recommandé. Mais si tu sais que tes client ne respecte pas parfaitement la norme Radical est peut être une meilleur alternative.
Pour les autre je ne les ais pas essayé.
# interessant
Posté par EauFroide . Évalué à 5.
Sujet très intéressant. C'est un retroshare en plus basique ou rien a voir? :)
Le logiciel est-il compatible streaming?
Si un utilisateur veut exporter des fichiers (par exemple données météo) directement sur le serveur (comme owncloud avec DAVFS) sans les conserver localement, ça tourne? Comment fait-il pour y accéder?
Si un Alice veut partager des ressources avec Bob, doit-elle ajouter toutes les machines de Bob ou suffit-il d'autoriser une machine de Bob pour que bob puisse propager les permissions à ses autres machines (voir a d'autres users telle que Pierre et vilainBigBrother)?
OUI :P
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: interessant
Posté par aurel (site web personnel, Mastodon) . Évalué à 5.
En beaucoup, beaucoup plus basique ^
Syncthing travaille uniquement au niveau du système de fichier: c'est là qu'il prend son input (les changements), et là qu'il les répercute (vers les autres machines). Il faut donc commencer par stocker en local ce qu'on souhaite envoyer. Il est possible de définir des hooks pour le versionning, de façon à déclencher telle ou telle action. Peut-être que ça pourrait être utilisé pour déplacer le fichier sur le serveur dans un répertoire où il pourrait être traité, plutôt que de propager sa suppression, tout en conservant un répertoire "d'échange" vide ?
Sinon, sans doute plus simple: un bête scp ou rsync pour envoyer les données au serveur ? Dans ce cas là, pas du tout besoin de synchronisation ?
Syncthing n'a pas de notion d'utilisateur (sauf pour l'interface web qui écoute sur 127.0.0.1, mais ce n'est pas lié au partage en tant que tel). Il semble possible de créer la topologie de synchronisation qu'on souhaite. Si Bob a une machine dont un répertoire est synchronisé avec celle d'Alice, j'imagine qu'il devrait sans problème pouvoir le partager à son tour avec d'autres machines, à lui ou à d'autres. D'ailleurs, c'est bien ce genre de topologies non-maximalement connexes qui existent lorsqu'on configure Syncthing avec plusieurs machines, transitoirement mais sans que ça gêne :)
[^] # Re: interessant
Posté par EauFroide . Évalué à 1. Dernière modification le 23 mars 2016 à 17:51.
Merci de nous faire découvrir ce logiciel ;)
Que se passe-t-il si tu configures deux machines en local puis que l'une d'elle change de réseau (par exemple un smartphone)? Kapout ou ça fonctionne? (je parle bien entendu pour ceux qui ont un routeur avec un loopback foireux qui bloque l'utilisation de l'IP externe/nom de domaine depuis l'intérieur du réseau)
Ça utilise du P2P? (ce n'est pas indiqué sur leur site :) )
Syncthing a l'air sympa pour remplacer rsync, avec plus de flexibilité.
Je dois justement mettre en place un système pour sauvegarder de lourdes bibliothèques de fichiers au cas où la machine qui gère owncloud tomberait en rade, ton tuto tombe a pics. ;)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: interessant
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
Syncthing est très flexible. Il est possible de rendre accessible chaque machine via une découverte globale (Global Discovery) ou une découverte locale (Local Discovery, sur le LAN). Lorsqu'on ajoute les machines avec lesquelles elle partage des répertoires, ces dernières peuvent être au choix 1/ découvertes automatiquement si c'est possible par l'un des deux mécanismes précédents, ou 2/ identifiées via adresse_ip:port. Du coup, que tu sois sur un réseau local où pas, Syncthing est capable de s'y retrouver automagiquement.
Un petit DNSMasq installé localement, qui redirige ton nom de domaine vers l'adresse IP locale, et transmet le reste à ton serveur DNS habituel ?
Ça me semble être une excellente idée. Contrairement à un rsync qui tournerait à intervalles réguliers et parfois pour rien, Syncthing+inotify se déclencherait à la demande. De plus, déclarer ton serveur ownCloud comme "Folder Master" te permettrait d'être sûr que la synchronisation soit unidirectionnelle.
[^] # Re: interessant
Posté par EauFroide . Évalué à 2.
Non ça ne fonctionne pas avec des machines mobiles (vu qu'en ipv4 les ip changent en fonction de si on est à l'intérieur ou à l'extérieur du réseau). Je me suis tapé un vide quand j'ai demandé au FAI indigne belge comment régler le problème proprement.
Les seules solutions que j'ai trouvé : utiliser Tor Hidden Service ou changer de routeur. (j'ai aussi trouvé ça, mais downgrader le firmware c'est trop naze pour la sécu).
Merci pour toutes tes réponses. Je pense que je vais tester et faire un petit tuto en retour sur raspberry pi pour voir les limites (automatisation, complexité du déploiement, etc)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: interessant
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
Autre solution: mettre un petit serveur DHCP / DNS sur ton réseau local, par exemple avec un Raspberry Pi. C'est lui qui gérerait les leases et la configuration des clients DHCP, transmettant à ces derniers sa propre adresse IP en tant que serveur DNS, depuis laquelle répondrait un DNSmasq configuré comme je le suggérais dans mon post précédent ?
[^] # Re: interessant
Posté par EauFroide . Évalué à 1.
Ce n'est pas bête, je vais tester cette solution.
Configurer les pc avec une interface graphique ça devrait être simple par contre j'ai toujours peur via ligne de commande (j'ai déjà bloqué la config réseau de plusieurs raspberry comme ça malgré d'avoir suivis les tuto :P).
J'avais aussi eu l'idée d'un mitm avec ettercap-ng mais je trouvais la solution trop laborieuse mdr
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: interessant
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Pour ta sauvegarde de ownclound, tu peux utiliser lsyncd, cela fait exactement ce que tu veux. Un espèce de RAID1 logiciel asynchrone avec en sous couche inotify, rsync et une fenêtre de temps. En gros, on enregistre tous les événements pendant 1min avec inotify puis on lance un rsync juste sur ces fichiers… Je fais le mirroir de ma forge avec une fenêtre de 2min ainsi depuis des années.
# Davical
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
On avait cela, cela marchait très bien même si la configuration des droits n'est pas triviale si c'est pour pas mal de personne. Depuis, on est passé à Zimbra avec lequel Thunderbird a bien plus de mal je trouve.
# Baïkal
Posté par Adrien BUSTANY (site web personnel) . Évalué à 5.
Radicale n'a jamais bien marché pour moi (j'ai du mal m'y prendre), Baikal est vraiment simple à installer et administrer, et marche sans soucis avec davdroid sur le téléphone, et Rainloop/Agendav sur le serveur.
[^] # Re: Baïkal
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Tu n'as pas de problème avec la synchronisation des contacts et leurs images avec Baikal ? Moi après une suppression et réimport des contacts, tout a bien fonctionné, sauf les avatars des contacts qui étaient dans une qualité timbre poste.
# Baikal
Posté par Calaad . Évalué à 5.
Bonjour,
J'utilise personnellement Baikal depuis quelques années et avec bonheur. Il fait juste ce que je lui demande (caldav, carddav, pour 2 utilisateurs) et il le fait bien. C'est bien documenté, ça mange pas de ressources, c'est facile à mettre à jour, c'est carré.
Ca se base sur Sabre/dav donc j'imagine qu'ils doivent être proches. Même chose pour Katana (http://sabre.io/katana/).
[^] # Re: Baikal
Posté par NiKaro (site web personnel) . Évalué à 2.
Je ne connaissais pas Katana, c'est une alternative intéressante à ownCloud pour la partie *DAV. Merci !
# Un excellent article
Posté par Cascador (site web personnel) . Évalué à 3.
Je vote oui pour la suite ;)
Et merci pour le partage !
Tcho !
# ownCloud ET SyncThing en même temps ?
Posté par Glandos . Évalué à 6.
Personnellement, j'ai mis mes photos, vidéos et musique sur mon serveur. J'y accède dans mon réseau local via NFS. Et quand je ne suis pas chez moi, j'ai dit à ownCloud de taper dans ces répertoires. C'est pas très rapide, mais ça fait le boulot.
Donc moi, si j'étais toi, je ferais ça : syncthing entre tes machines, pour la synchro au quotidien. Tu rajoutes un ownCloud qui a aussi syncthing et qui permet de partager finement, avec une belle interface web. ownCloud permet de définir des montages locaux, c'est très pratique.
[^] # Re: ownCloud ET SyncThing en même temps ?
Posté par aurel (site web personnel, Mastodon) . Évalué à 5.
Une telle solution ne dispense malheureusement pas de l'installation/maintenance de ownCloud, alors que mon objectif premier est de remplacer une solution décentralisée par une distribuée: simplifier, pas compliquer.
Cela dit, suivant les cas d'utilisation, je trouve aussi une solution hybride clairement très intéressante :)
# CalDAV et CardDAV
Posté par Glandos . Évalué à 1.
Personnellement, je suis sous Davical, mais c'est historique. Radicale est tentant, parce que c'est du python, mais c'est un sujet à troll. Il est cependant assez basique, mais pour un mono-utilisateur, ça ira largement.
Baïkal vient de passer sous la coupe de SabreDAV, donc il devient franchement sexy. Davical est clairement complet, mais avec une interface impossible. Théoriquement, on peut faire des tickets, des partages partiels, des permissions ultra-fines. Et en pratique, c'est jamais utilisable :)
Bref, si tu tentes un Baïkal, je serais ton lecteur :)
# Retour d'expérience abandon de owncloud
Posté par rahan . Évalué à 4.
Un petit retour d'expérience de quelqu'un qui veut aussi quitter Owncloud pour les mêmes raisons que toi : toutes mes mises à jours précédentes ce sont terminées avec les mains dans le cambouis. Et pourtant je n'ai rien d'exotique avec les fichiers en local, une BDD MySQL, 3 utilisateurs avec plusieurs calendriers et carnets d'adresses partagés.
Pour la synchronisation des fichiers j'utilise Seafile. C'est beaucoup plus propre que Owncloud même si ça ne gère que la partie fichiers: synchronisation/partage/publication. Les clients linux et Android marchent mieux. En résumé : moins de fonctionnalités annexes mais plus robuste et professionnel.
Mon problème a été depuis 6 mois de trouver un remplaçant au serveurs Carddav et Caldav d'Owncloud. J'ai testé:
DAVical (que j'utilisais il y a longtemps) : c'est une usine à gaz. Il permet une gestion fine des droits et partage mais j'ai l'impression que c'est tellement complexe que je ne maitrise pas vraiment ce que je fais. Il lui manque en fait les calendriers/carnets en ligne.
Radicale : Plus simple. Le partage entre utilisateurs me semble très rudimentaire. Encore une fois, pas de calendriers/carnets en ligne.
Baikal : Je n'ai pas trouvé le partage. La version 2 a les calendriers/carnets en ligne.
Zarafa : Assez tentant. Un joli groupware avec une webapp qui gère tout (mail, calendriers, carnets, partages…). Il ne semble pas gérer les connexions Carddav (mais il y a un serveur Caldav).
Voilà pour mon retour d'expérience. Ce qui me manque vraiment c'est un serveur Card/Caldav qui gère les partages et avec une interface web. Je sais que je pourrais utiliser InfCloud mais il a du mal à trouver les calendriers partagés avec la plupart des serveurs.
[^] # Re: Retour d'expérience abandon de owncloud
Posté par rycks . Évalué à 8.
Bonsoir, un petit message antistress …
depuis la version 7 de owncloud je n'ai plus aucun problème de mise à jour, un coup de ./occ upgrade et zoup quelques minutes plus tard me voilà à la version suivante…
parfois il faut aussi dire qu'il y en a chez qui ça marche pour de vrai sinon à lire les forums on finis par croire que rien ne marche jamais :)
a+
Éric
eric.linuxfr@sud-ouest.org
[^] # Re: Retour d'expérience abandon de owncloud
Posté par ʭ ☯ . Évalué à 5.
+1 (euh non, +2 car j'ai 2 serveurs oc qui se mettent à jour sans souci). J'utilise les paquets de ma distrib, c'est fait pour!
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Retour d'expérience abandon de owncloud
Posté par Adrien . Évalué à 10.
A priori les développeurs de Owncloud ne veulent pas que les distributions fournissent Owncloud :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816376
Bref, les dev n'ont visiblement rien compris au rôle des distributions Linux, c'est assez moche ;-(
# Les deux, suivant l'usage
Posté par Zatalyz (site web personnel) . Évalué à 2.
Chez moi, j'utilise owncloud et syncthing. Syncthing pour mes données personnelles, je le trouve super pratique et ça me suffit parfaitement. J'ai mis une instance sur un de mes serveurs, auquel mes autres appareils se synchronisent, comme ça c'est toujours à jour. Les mises à jours se font toujours sans souci. Un régal.
J'ai cependant aussi mis en place Owncloud à côté, pour le côté collaboratif justement. Le fait de pouvoir partager facilement des dossiers et fichiers via le web me sert pas mal. J'ai des dossiers partagés avec d'autres personnes. Owncloud est plus simple à gérer quand il s'agit de faire du collaboratif ; côté maintenance je n'ai pas encore eu de problème, et pour les gens avec qui je partage, je leur propose d'installer le client, "comme dropbox" : ça a le mérite d'être simple pour eux, voir familier pour ceux qui utilisent dropbox.
J'ai découvert le partage d'agenda et de contacts grâce à owncloud… mais ça n'a qu'un intérêt limité pour moi, car je gère ça quasiment toujours depuis le même appareil.
Ma préférence niveau utilisation va à Syncthing, parce que c'est un logiciel plus simple, sobre tout en étant super efficace, owncloud étant un peu usine à gaz à côté. Ceci dit, les deux couvrent des besoins différents, et font bien leur boulot. Mais si je n'avais pas l'aspect collaboratif je me contenterais de Syncthing.
# Comment ça marche ?
Posté par barmic . Évalué à 3.
Au final si j'ai 3 machines A, B et C et que je souhaite synchroniser le dossier /foo/bar de la machine A.
Tout est cool.
Maintenant j'ai les machines A et B d'allumés => B:/truc == A:/foo/bar
Puis j'éteins A et j'allume C.
Est-ce qu'il y a une synchro entre B:/truc et C:/machin ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Comment ça marche ?
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
Pas sans avoir également associé B:/truc et C:/machin.
En pratique, lorsque du déclare un nouveau répertoire partagé sur ta machine locale, tu peux choisir avec quelle(s) machine(s) est-ce que tu veux le partager. Il te suffit donc de cocher les cases qu'il faut pour définir B et C comme pairs pour A, A et C comme pairs pour B, et A et B comme pairs pour C. Dès que tu le fais sur la machine que tu configures, un message apparait sur celle(s) avec lesquelle(s) tu souhaites établir le partage. De cette façon, ce n'est pas si laborieux que ça en a l'air.
Cerise sur le gâteau, à moins que j'ai la berlue, si toutes les machines sont allumées et que seule C n'est pas à jour, elle téléchargera le contenu depuis A et depuis B.
[^] # Re: Comment ça marche ?
Posté par barmic . Évalué à 4.
Ça a l'air tout de même sacrément relou à utiliser, il te faut créer un graphe complet entre toutes les machines qui sont censées partager un dossier.
Je n'ai pas essayé btsync, mais je présume (vu ce que propose bitorrent) que le partage est plus simple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Comment ça marche ?
Posté par aurel (site web personnel, Mastodon) . Évalué à 4.
Comme je disais, ce serait relou s'il fallait configurer ex nihilo chaque machine. Là, il suffit de cocher sur chaque répertoire les machines avec lesquelles on souhaite le partager, puis de valider sur ces dernières. Ça semble pénible - ça l'est à écrire, j'imagine que ça l'est aussi à lire -, mais pour l'avoir fait plusieurs fois, ce n'est heureusement pas du tout le cas :)
Pour autant que je me souvienne, BTSync, quant à lui, identifie machines et répertoires par un simple hash, qu'il suffit de rentrer sur toutes les machines qui doivent partager un contenu commun. C'est plus simple à configurer, mais la contrepartie est que quiconque possède ce hash peut accéder au contenu, alors que Syncthing impose la reconnaissance mutuelle des machines a priori. En plus BTSync n'est ni opensource ni libre.
# Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . Évalué à 9. Dernière modification le 24 mars 2016 à 11:37.
Salut,
déjà merci pour ce journal, il est intéressant et j'aimerais aussi voir d'éventuelles suites.
Juste une petite remarque, il y a une tendance à penser que quelque chose de « distribué » (dans le sens utilisé ici) est nécessairement mieux que quelque chose de « décentralisé » (dans le sens avec un serveur intermédiaire). C'est à mon sens une erreur.
Un système « distribué » comme compris ici (que j'appelle plutôt « entièrement pair à pair » pour éviter les confusions), ne se passe pas de serveur, c'est juste que le serveur est placé au niveau du client, ou en d'autres terme c'est le client qui fait le boulot.
C'est intéressant sur plusieurs points (on devrait pouvoir couper une partie du réseau sans grosse conséquence sur les autres par exemple), et c'est clairement très très intéressant sur le plan technique/recherche.
Mais placer le serveur au niveau du client a ses conséquences : le client devant faire le boulot, c'est autant en plus sur la bande passante et la charge processeur, ce qui est particulièrement gênant pour le monde mobile où ça va en plus influer sur la batterie.
Il y a d'autres problèmes : l'accessibilité des données par exemple ; et d'ailleurs on le voit dans ton journal, dans le paragraphe « Pseudo synchronisation asynchrone » :
En gros tu mets un serveur en place…
Autre soucis : l'identifiant. Il n'y a pas aujourd'hui — à ma connaissance — de solution simple et facile pour identifier une machine sans serveurs intermédiaires.
des hashs et des QR codes, je trouve pas ça très pratique moi, les QR codes sont plutôt des cache-misères.
Le choix d'un serveur intermédiaire est généralement voulu, et en simplifiant, il suffirait de mettre serveur et client sur la même machine pour en faire ce que tu appelles « distribué » (et de trouver un substitut au DNS avec probablement à la clef des hashs imbitables et autres QR codes).
J'avais d'ailleurs fait un billet sur mon blog à ce sujet, lisible ici.
Enfin bref, du 100% pair à pair c'est intéressant, mais c'est pas forcément mieux qu'un serveur intermédiaire, à mon sens du moins.
Si ton but principal c'est la simplification de la configuration, c'est peut-être de ce côté qu'il faut regarder (un serveur intermédiaire ne devrait pas être synonyme d'un truc relou à installer).
Ceci-dit, je vais lire tes prochains articles avec intérêt :)
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par aurel (site web personnel, Mastodon) . Évalué à 1.
SàT Goffi,
Je te rejoins complètement.
Ce qui m'intéresse dans cette histoire, c'est d'explorer en quoi est-ce qu'une solution distribués peut être une alternative crédible à une solution décentralisée. Ces dernières années, le principal problème autour des usages d'internet me semble être celui de la centralisation. Si les logiciels le supportent, la décentralisation est possible mais repose entre les deux extrêmes caricaturaux suivants: un hébergement de service mutualisé (genre Framasoft, C.H.A.T.O.N.S. ou sandstorm), et un hébergement individuel autonome dans son garage. Dans le premier cas, il reste un "centre" qui échappe à l'utilisateur. Dans le second, le poids de la mise en place et de l'entretien de ce "centre" lui incombe. Aucun de ces horizons ne me semble désirable au point de ne pas investiguer celui des services distribués, pour justement, entre autre, envisager leurs limitations. C'est de la prospective.
En pratique, j'aimerais donc essayer de trouver le meilleur compromis subjectif entre les services dont je dispose et les ressources que ces derniers me demandent, sachant que mes données ne doivent pas être confiée à un tiers. J'ai chez moi une machine dédiée qui héberge tout un tas de service, je voudrais l'alléger où c'est possible, au point de potentiellement m'en passer.
Puisque tu passes par ici et que tu connais bien la question, j'en profite: je me pose la question également pour mon serveur XMPP (ejabberd) dont j'ai un usage totalement basique. Je vois Tox, ring.cx et ricochet comme outsiders. Si tu as le temps, je serais ravi - et probablement pas que moi - d'avoir ton avis sur ces derniers.
Aurel.
PS: Petite précision: la "synchronisation asynchrone" fonctionne sans être un hack: la machine supplémentaire est un serveur autant qu'un client, et sans elle le service contenu à être rendu, quoiqu'en mode dégradé. La dépendance est donc bien moindre que dans le cas d'un système client/serveur décentralisé.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Oui il y a plusieurs questions à prendre en compte. Pour ma part je ne suis pas gêné d'avoir un serveur géré par une entité si j'ai confiance en elle (une assoce que je connais bien par exemple), mais même dans ce cas je chiffrerai de bout en bout les infos très sensibles (par exemple un mot de passe que je donne à quelqu'un). Pour faire un parallèle, j'ai très souvent laissé les clefs de chez moi à des inconnus (je suis sur des sites d'hospitalité comme BeWelcome).
Il y a aussi des questions écologiques (mutualiser les ressources sera toujours mieux de ce point de vue), d'entretien (en dehors du serveur pour ton logiciel lui même, la gestion des sauvegardes ou des risques d'intrusion ne vont a priori pas être géré par ton logiciel final, même s'il est entièrement P2P). Bref, c'est pas mal si une ou plusieurs personnes s'en occupent sérieusement. Je pense que le mieux est de permettre les 2 : mutualiser et si voulu autohébergement facile.
Tox j'ai essayé mais il y a plus d'un an, avec un des frontaux les plus communs (je ne sais plus lequel, peut-être Venom). J'avais apprécié la simplicité (en dehors du hash quasi inévitable, on lance est c'est OK), mais impossible d'avoir une vidéo fonctionnelle, et c'est pour ça que je voulais l'utiliser. À vrai dire même avec Jitsi j'ai pas eu des résultats très probants (pas essayé non plus depuis longtemps), et c'est encore Mumble qui me donne les meilleurs résultats, mais c'est audio uniquement. Il faut dire que je suis souvent dans des conditions mauvaises (pas de connexion directe, mauvais débit, etc).
Ring et Ricochet pas essayé, Ricochet leur technique pour couvrir le bruit semble intéressante, mais c'est un cas d'utilisation particulier, pour des messages très sensibles, pas sûr que ça soit viable pour de la conversation de tous les jours (encore une fois, question de ressources).
Dans tous les cas ces projets vont accuser un énorme retard sur XMPP, car il y a beaucoup de problèmes qui sont déjà réglés dans ce dernier, et qu'ils vont avoir. Et c'est souvent plus difficile quand il n'y a pas de serveur intermédiaire. Sans parler des fonctionnalités à implémenter (des trucs comme la correction du dernier message, l'état de discussion, la gestion des archives, des appareils multiples connectés en même temps, etc).
Tiens d'ailleurs XMPP est un cas particulier : c'est un réseau décentralisé « hybride », c'est à dire qu'il y a des serveurs intermédiaires mais il est capable de faire du P2P (j'ai un article à publier sur Jingle à ce sujet). On est aussi plusieurs à envisager à terme d'en faire un réseau entièrement pair à pair en regroupant serveur et client (optionnellement), ça ne se fera peut-être jamais, mais c'est techniquement possible (on peut déjà se passer de serveur en local).
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
Concernant la gestion de multiples appareils, il y a des tickets ouverts sur github, par exemple celui-là, ainsi qu'un document en cours de rédaction.
Il y a du boulot, c'est visiblement en court de réflexion.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Mildred (site web personnel) . Évalué à 1.
Je serais curieuse de savoir comment ça serait possible. J'imagine déjà plusieurs problèmes :
@et un nom de domaine ne semble plus adapté.Et je suppose que le résultat ne serait pas compatible avec le réseau XMPP fédéré actuel. A la limite, c'est pas si gênant, mais peut on encore appeler ça du XMPP ?
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Ben en fait c'est déjà plus ou moins ce qu'il passe qu'on on utilise XMPP à travers TOR. Un nom de domaine reste adapté, c'est juste qu'il est lié à un autre système que l'actuel. À l'heure actuelle tu peux même utiliser une IP directement si tu veux.
XMPP n'est pas forcément lié à TCP, il y a tout un tas de possibilités envisageables.
Pour les autres problèmes, je ne vais pas supputer, du 100% pair à pair n'est clairement pas ma priorité pour le moment, il y a d'autres problèmes à régler avant, et comme je l'ai dit plus haut un serveur intermédiaire a de nombreux avantages et je pense qu'à l'heure actuelle c'est préférable. Dans l'idéal, il serait possible dans le futur de choisir 100% P2P ou avec serveur intermédiaire, mais bon on n'en est pas là.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Mildred (site web personnel) . Évalué à 2.
Pour ma part, je vois un inconvénient principal : on devient dépendant du serveur qui maintient notre JID. Que ce soit le nôtre ou pas. Typiquement, j'ai un compte sur jabber.fr, que je n'utilise plus, parce que les certificats SSL n'ont pas été renouvelés. La migration vers un autre serveur est trop coûteuse pour que j'en voit l'intérêt.
Comparé a IRC, peu importe le serveur sur lequel je me connecte, ça marche toujours aussi bien. Alors certes, IRC n'offre pas le même service, mais finalement ça me convient mieux.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
C'est surtout du nom de domaine que tu dépends, si tu veux pouvoir bouger facilement, en prendre un et le faire suivre ton serveur est une option. Mais la migration entre les comptes est un truc à travailler en effet.
jabber.fr manque de bras, il n'y a plus qu'un admin actif à ma connaissance, et vu la place du serveur (souvent le premier sur lequel on tombe quand on est francophone), un coup de main serait sans doute très apprécié.
XMPP est capable de fonctionner de la même façon, avec les connexions « anonymes » (anonymes parce que pas de JID fixe, aucun rapport avec l'anonymat à la TOR). Et là aussi c'est d'autres admins qui gèrent les certificats ou état du serveur (et c'est même pire parce que les salons sont très liés aux serveurs).
IRC fait sont boulot depuis plusieurs dizaines d'années, si ça te convient c'est très bien, rien à redire dessus.
XMPP bien plus que de la messagerie, comme je le répète régulièrement, en ce moment on le montre avec son utilisation pour du blogage.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
Ces problèmes que tu décris m'évoquent Ricochet, mais ce dernier n'a rien à voir avec XMPP. C'est un système de messagerie instantanée anonyme et chiffré de bout en bout qui protège aussi bien le contenu que les métadonnées. Pour ce faire, il passe par TOR, et remplace l'identification par nom d'utilisateur / nom de serveur par le nom d'un service caché instancié en parallèle du client. La question du passage du NAT est donc déléguée à TOR, ainsi que le changement d'adresse IP également.
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Tout ça XMPP le fait déjà également (il est parfaitement possible de passer par Tor — faut pas mettre les majuscules, sinon y'a les gars de nos oignons qui nous enguelent ;) — ça fait même un moment qu'on parle d'une version spécialisée de SàT qui fait ça directement).
Ce qui avait l'air intéressant sur Ricochet quand j'avais regardé (mais pas testé), c'est qu'il ajoute du bruit pour rendre plus difficile l'analyse du trafic. Sûrement utile dans les cas très sensibles, mais ça me semble à double tranchant sur l'utilisation des ressources processeur/réseau (encore une fois pas testé).
[^] # Re: Ne pas jeter le bébé avec l'eau du bain
Posté par Mildred (site web personnel) . Évalué à 2.
Tout a fait, et ça peut aussi poser des problèmes sur les nœuds a la périphérie du réseau comme les appareils mobiles qui n'ont pas forcément la bande passante ou la batterie nécessaire.
Par contre, malgré cela, il faut tout de même tendre vers du distribué dans le sens ou chaque nœud fait partie intégrante du réseau. Dans le cas de synthing, on a le choix de ne pas avoir de serveur (et donc une dispo des données moins importante) ou monter (ou louer) un serveur pour avoir une dispo plus importante. Le choix est possible et est fait en toute connaissance de cause.
# Cozy Cloud
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Je vais faire un peu de pub. Je travaille pour Cozy Cloud et je te conseille d'y jeter un coup d’œil. La partie synchronisation de fichiers est encore loin d'être au niveau d'OwnCloud et SyncThing. J'y travaille mais ça va prendre du temps (ça ne sera probablement pas dans les six mois qui viennent).
Par contre, pour la partie calendrier et contacts, on a déjà quelque chose qui marche bien et joli en plus.
Côté sécurité, tout n'est pas parfait. On a des progrès à faire pour sandboxer les applications tierces. Mais si on se restreint aux applications distribuées dans le store, ça tient bien la route.
[^] # Re: Cozy Cloud
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
Merci beaucoup, en effet c'est très joli !
Je n'ai jamais eu l'occasion d'essayer CozyCloud, ça donne envie :)
# des utilisateurs d'unison?
Posté par albatar . Évalué à 5.
Des retours d'expériences sur unison?Nottament la version Android?
Niveau sécu, je suis moyen chaud de mettre ma clé ssh sur mon téléphone.
[^] # Re: des utilisateurs d'unison?
Posté par zurvan . Évalué à 2.
je ne connaissais pas la version android. Bon, j'ai un gros volume de données que je partage avec Unison, donc ce n'est pas pour mes périphériques android. L'appli android n'est pas très bien notée et ne semble d'ailleurs pas libre.
Sur PC, je trouve unison pratique, pour mon usage. En revanche, pour un utilisateur non averti, il n'est pas très aisé : seulement en anglais, pas de possibilité de classement par colonne (par exemple pour voir en priorité ce qui a changé dans un sens ou dans l'autre), pas de réplication automatique dans un seul sens (pour faire une sauvegarde simple sans risquer d'effacer des fichiers important dans son dossier de travail principal), gestion des conflits pas très pratique (simple diff, pas de possibilité de renommer les fichiers conflictuels, faut le faire à la main).
Mais unison c'est le top pour gérer relativement finement ses synchronisations, si on vérifie les sens de changement et les fichiers modifiés, on risque moins de commettre d'impairs (je n'ai pas souvenir d'avoir perdus des données à cause d'Unison).
J'aime bien owncloud, mais les dernières mises à jour ont été assez problématiques chez moi, avec beaucoup de travail pour résoudre les problèmes. Je tends le dos pour la dernière mise à jour vers la version 9… (et retarde l'échéance).
De plus, sur certains clients pas toujours allumés, ça arrive que lorsqu'on les réactive, ils renvoyent des fichiers depuis longtemps supprimés sur le serveur, ça met un joyeux fouilli dans son classement… bref, owncloud ça marche pas trop mal, mais je n'ai pas une confiance absolue dedans…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: des utilisateurs d'unison?
Posté par zurvan . Évalué à 3. Dernière modification le 29 mars 2016 à 11:26.
Bon, je tente quand même ma mise à jour de OwnCloud, ça commence bien :
Super, calendrier et contacts, juste un des trucs que j'utilise le plus… sachant que dans une version précédente une mise à jour incompatible déjà désactivé ces applications et qu'il avait fallu refaire une migration manuelle vers le nouveau format…
Et ce n'est qu'une mise à jour de la 8.1.1 vers la 8.2.3.
Mais c'est étrange, une fois la mise à jour faite, j'ai réactivé Calendar et contact et tout semble refonctionner.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: des utilisateurs d'unison?
Posté par zurvan . Évalué à 3.
Sur un autre serveur j'ai ce genre de message sympa pour passer à la version 9 :
Et là j'ai juste utilisé leurs paquets pour ma distribution (Debian).
Comme sur mon premier serveur j'ai la dernière version 8.2.3. je tente la mise à jour vers la version 9. Et là, paf l'owncloud : "General error: 10 disk I/O error)" (apparemment c'est un bug qui affecte plusieurs personnes). Bon, je reviens à la version 8.2.3 en attendant… et je vais tester syncthing…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Même problématique
Posté par Mildred (site web personnel) . Évalué à 2.
Pour ma part, je partage cette problématique depuis un moment. Passer de quelque chose de décentralisé a quelque chose de complètement distribué, et c'est ce qui me fait abandonner progressivement XMPP/Jabber.
Je vous partage ici quelques autres solutions :
[^] # Re: Même problématique
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
J'avais déjà remarqué en te lisant par-ci par-là que nous avions certains intérêts en commun :) Est-ce que c'est un intérêt personnel, ou est-ce qu'à travers toi ces choses tarabusteraient également "ton employeur" ?
Je suis en train de tester Tox, et ferai sans doute faire un retour sur la messagerie instantanée quand j'aurais assez de recul.
[^] # Re: Même problématique
Posté par Mildred (site web personnel) . Évalué à 2.
C'est principalement un intérêt personnel, après cela n'empêche pas mes collègues de s'intéresser a ce genre de choses également.
# Retour de la centralisation
Posté par Michaël (site web personnel) . Évalué à 2.
Ce qui revient au final à adopter une architecture centralisée!
[^] # Re: Retour de la centralisation
Posté par zurvan . Évalué à 4.
pas tout à fait, puisque si la machine C n'est plus disponible, il est possible de laisser allumer à la place la machine A ou B…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Syncany
Posté par Alex G. . Évalué à 1.
Désolé j'arrive tard dans la discussion.
Merci pour ce journal, qui a mon avis aurais largement pu faire l'objet d'une dépêche. J'espère qu'il y aura des suites :-)
Merci en particulier pour la discussion décentralisé / distribué. C'est moi aussi une question qui m'intéresse.
Je pense que j'irais regarder syncthing. Par contre j'ai aussi vu le logiciel syncany. Les buts et publiques visés me semble un peu différent. Syncany permet de déposer puis mettre à jour des fichiers, en minimisant l'espace (différentiels et déduplication) et en utilisant des données chiffrées. L'idée est de pouvoir utiliser un serveur "non sur" comme relais entre deux machines à synchroniser.
Je ne sais pas si quelqu'un a de l'expérience avec cet outil et s'il peut en faire un retour.
# Retour de test
Posté par EauFroide . Évalué à 1.
Je viens de finir de l'essayer, voici le petit retour qui, je l'espère, te sera utile pour le prochain épisode :)
J'en ai profité pour faire un petit tuto d'installation que tu pourra trouver ICI :)
L'installation est très rapide grâce à l'installation via apt (et du copier-coller).
Lors du premier lancement sur des machines dédiées, il ne faut pas oublier d'aller autoriser l'accès à la WEBUI depuis les autres machines (par défaut uniquement 127.0.0.1 peut accéder à l'interface), sauf si vous ne l'utilisez que via Hidden Service.
Pour ce faire mettez à 0.0.0.0 à dans /home/pi/.config/syncthing/config.xml
Pensez à activer https dans les options sur la WEBUI si vous l'utilisez autrement que via Hidden Service ;)
On apprécie le thème Dark (sombre) qui évite de s'éclater les yeux durant la nuit.
Le logiciel cherche les autres machines (discovery) toutes les 30 minutes sur internet et toutes les 30 secondes sur le réseau local.
Les côtés négatifs maintenant :
dans chaque dossier racine partagé, syncthing crée un fichier .stfolder, se qui peut s'avérer désagréable si le même dossier est partagé avec un autre logiciel (genre owncloud qui va le référencer), surtout si un user supprime ce fichier qui provoque une erreur.
pas de service par défaut (pas de sudo service syncthing start) et j'ai l'impression que le logiciel "parle trop" dans le terminal (se qui, si je ne me trompe, peut provoquer de grosses augmentations de la taille des fichiers logs si on l'utilise en script sur raspberry pi).
utilisation de sha256 (sachant qu'il existe des ASIC mineur pour sha256 (crypto-monnaies), ça aurait été pas mal de privilégier sha512 histoire d'augmenter la sécu))
Le logiciel n'est pas du tout comparable a owncloud :
owncloud fait du cloud (la synchronisation n'est qu'une des options parmi d'autres (streaming, davfs, calendrier, contact, partage précis, etc)), tandis que syncthing ne fait QUE de la synchronisation distribuée (mais il a l'air de le faire bien). Se serait par contre intéressant de savoir si syncthing tourne en F2F pure ou bien si des informations s'exfiltrent comme dans le réseau bittorent habituel (afin de chercher des pairs).
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Retour de test
Posté par erdnaxeli (site web personnel) . Évalué à 3.
On peut aussi décider de n'administrer sa machine qu'en local. Personnellement pour les machines distantes je fais un petit tunnel SSH, c'est rapide, efficace, et sécurisé.
Ça c'est effectivement dommage, mais je pense qu'écrire un fichier de service pour systemd ne doit pas être bien dur, je vais regarder ça tiens (et on remarquera que cette idée ne me serait jamais venu avec un init nécessitant un script bash, sans vouloir relancer un troll :p).
Ça dépend de tes réglages concernant les logs. Mais avec un lograte + de la compression ça devrait limiter fortement l'impact sur l'espace disque. Le niveau de log ne semble pas réglable côté Syncthing, c'est effectivement un peu dommage.
Oui si on en le désactive pas par défaut il y a un système de découverte très semblable aux trackers torrent, qui fait donc fuiter votre ID, IP et port.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Retour de test
Posté par EauFroide . Évalué à 1. Dernière modification le 09 avril 2016 à 01:23.
oui SSH et Tor Hidden Service utilisent tout deux 127.0.0.1 pour joindre les services (si on les a réglé ainsi il va de soit).
Avec tor hidden service ça fait vraiment ghost, genre la machine tu peux la brancher n'importe où elles fait son job et tu y a accès (WEBUI et sync avec UPnP) sans rien faire au réseau :P
l'option à cocher "Global Discovery" non?
Si tu sais comment les réduire au stricte minimum voir tout désactiver, je suis preneur ^ ^ (c'est la hantise des raspberry pi, surtout mail.log qui a crash un des miens).
En attendant que quelqu'un qui sait faire un service ne partage, j'ai fais un script de démarrage (à appeler via /etc/rc.local):
screen doit être installé
et d’arrêt :
Source: voir les liens que j'ai posté avant
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Retour de test
Posté par Sufflope (site web personnel) . Évalué à 3.
Vu qu'apparemment tu lances tout bêtement le binaire syncthing sans aucune option, et que tu le tues sans ménagement pour arrêter, l'équivalent systemd serait sûrement (j'ai absolument pas testé) :
C'est valable si le binaire syncthing lancé est bien l'exécutable final ; si c'est un wrapper qui fork, il faut ajouter
à la section Service.
Note que c'est le strict équivalent de ton script ; si tu veux un autorestart en cas de fin innatendue (segfault…), faut rajouter
à la section Service (avec x le nombre de secondes à attendre).
À écrire dans /etc/systemd/system/syncthing.service, et ensuite :
systemctl daemon-reload
systemctl enable syncthing
systemctl start syncthing
# Quelques détails techniques
Posté par erdnaxeli (site web personnel) . Évalué à 2.
Si des gens se demandent comment ça se comporte avec un NAT, et bien ça marche sans soucis. Précision : j'ai testé le cas d'une machine derrière un NAT vers une machine sans NAT.
Si les deux machines sont chacune NAT-ées, il y a plusieurs solutions (mais que je n'ai pas testées). La plus simple est d'utiliser UPnP. Si cela n'est pas possible, on peut utiliser un serveur relais (qui doit lui être directement accessible). Il existe des serveurs relais publiques, mais on peut bien sûr en installer un soi-même (même si rappelons-le la communication est chiffrée de bout en bout).
Une dernière précision pour terminer concernant le système de découverte. En local c'est facile, c'est du broadcast (IPv4) ou multicast (IPv6). Par contre pour se découvrir sur l'Internet mondial (avec un grand I) il faut utiliser un serveur de découverte auquel on se déclare. Pareil que pour les serveurs relais, il en existe des publiques mais on peut aussi installer le sien. Par contre à la différence du serveur relais, le serveur de découverte possède votre ID, IP et je pense le port, ce qui en fait un gros annuaire. On peut donc aussi désactiver la découverte et préciser l'IP et le port du serveur distant lorsqu'on veut partager du contenu avec (à noter qu'avec UPnP le port ouvert au public n'est visible que dans un message dans les logs du client, et pas sur la GUI web).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.