aurel a écrit 1319 commentaires

Tu as aussi WooCommerce, qui est un plugin pour le classique Wordpress.

Suivant le positionnement de ton amie, il y a aussi le très connu alittlemarket, qui est une filiale d'Etsy. Il y a potentiellement beaucoup d'inconvénients à passer par un site dans ce genre, mais suivant les volumes de ventes qu'elle envisage de faire, ça peut être une option à considérer.

… à faire avec cet article (en anglais).

Autre application, le tout récent Whatsapp Desktop.

C'est aussi Electron qui est utilisé par Mozilla pour son projet Tofino, travail exploratoire autour de l'interface utilisateur des navigateurs (source anglophone).

Le lien entre electron et chromium, et donc entre tofino est chromium, est perçue par certains comme un signe inquiétant concernant les principes et les bases techniques historiques de Mozilla.

Vraiment très sympa, ce projet. Utilisateur de tt-rss, j'apprécie énormément les raccourcis claviers qui permettent par exemple de passer d'un article à l'autre sans avoir à toucher la souris. C'est le genre de chose qui enlarge tellement la productivity qu'il est difficile de s'en passer :)

Merci beaucoup d'avoir autorisé la création de comptes indépendants, je suis sûr que ça va permettre à beaucoup d'entre nous de tester :)

Ce qui est très rigolo concernant celui-là, c'est qu'un jour il sera vrai. À ce moment-là, on rigolera moins :-/

Est-ce que le RequestPolicy ne fait pas un peu doublon avec le mode "Dynamic Filtering" de uBlock Origin ?

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.

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.

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.

Merci beaucoup, en effet c'est très joli !

Je n'ai jamais eu l'occasion d'essayer CozyCloud, ça donne envie :)

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

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.

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 ?

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.

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

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

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.

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

Un petit DNSMasq installé localement, qui redirige ton nom de domaine vers l'adresse IP locale, et transmet le reste à ton serveur DNS habituel ?

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

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

C'est un retroshare en plus basique ou rien a voir?

En beaucoup, beaucoup plus basique ^{^}

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?

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 ?

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

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

Ce premier test semble laisser penser le contraire: le RP3 ne serait qu'un peu plus rapide que le RP2, mais chaufferait plus, et surtout consommerait beaucoup plus.

Dans la mesure où il intègre le wifi et le bluetooth en plus, c'est à un RP2 avec dongle wifi et bluetooth qu'il faudrait peut-être le comparer ?

En plus des solutions proposées plus haut, tu as aussi Parrain Linux, qui te permet d'identifier des personnes disposées à t'aider et qui habitent près de chez toi.

Tu peux aussi trouver des contacts sur les réseaux sociaux, par exemple sur Diaspora en t'inscrivant sur Framasphere et en y demandant un coup de main.

A.

kpartx -d ... ?

cf. ce journal ?

s/delta diff/delta sync/g, évidemment…

Conceptuellement, ce n'est pas possible de ne transférer que les fichiers qui ont changé sans avoir accès au contenu de ces derniers, donc à pouvoir les déchiffrer tant localement que sur NET, pour pouvoir les comparer.

Si tu laisses NET les déchiffrer, c'est que NET a la capacité de le faire, et donc que NET est vulnérable au moment du déchiffrement, voire lorsqu'elle est offline suivant la façon que tu as de lui faire déchiffrer.

Si tu confies le déchiffrement de NET à ta machine locale pour faire le delta diff, par exemple en montant NET via SSHFS, le calcul du delta diff nécessitera le déchiffrement de tout ce qui est stocké sur NET, et donc son transfert depuis NET en local.

Seule solution: faire le delta diff sur tes données chiffrées. Ça suppose qu'elle le soit sur ta machine locale, par exemple avec ecryptfs ou encfs qui laissent accessible l'arborescence chiffrée. Si tes données locales ne sont pas chiffrées, tu peux utiliser la fonction "reverse" de encfs, qui te génère, à partir de données en clair, une arborescence chiffrée que tu pourras rsync'isée où tu le souhaites et en toute sécurité - ou en tout cas, avec la sécurité de encfs.

A.