discussions:Soxyd

  • topics

    • Remise à zéro | Jan. 18, 2011

      Bonjour.

      Cela fait un certain temps que je n'ai pas donné de nouvelles concernant ce projet. Aujourd'hui, je soumet l'idée de le revoir intégralement.

      Pour commencer, je tiens à énumérer des problématiques que le projet Soxyd soulevait jusqu'à présent, qu'elles aient été évoquées sur ce forum ou pas :

      1. la grande diversité des accès à Internet rend complexe la configuration pour un utilisateur novice, alors même que le principe du projet était de se rapprocher au maximum de ces personnes. Il n'était même pas possible de s'appuyer sur de l'IPV6 fiablement.
      2. Ce système était totalement indépendant, ce qui peut être vu comme une force, mais ne correspondait pas forcément au côté social
      3. Il n'est pas facile pour tout le monde de maintenir un service optimal, que ce soit à cause de coupures de courant ou de connexion
      4. Nous pensions packager un nombre déterminé de services, sur un matériel qui plus est peu puissant. Or, rien n'indique que les besoins de chaque utilisateur potentiel seront les mêmes, et coïncideront exactement avec ce que nous fournirons
      5. Il est évidemment nécessaire d'acquérir un boîtier (Sheevaplug ou autre) pour utiliser ce projet, ce que peu de gens sont prêts à faire.

      C'est après une longue discussion avec Loïc Dachary qu'ont émergé les points suivants, servant de base à une nouvelle conception du projet :

      • Au lieu d'avoir x utilisateurs séparés, on considèrera des groupes d'utilisateurs en confiance mutuelle (les gens normaux appellent ça des amis ;) ), de taille faible à moyenne (la confiance étant inversement proportionnelle au nombre d'individus).
      • Chaque utilisateur d'un groupe fournira des ressources, qu'il s'agisse d'un Sheevaplug, d'une VM sur un pc, d'un serveur dédié...
      • Tous les hosts mis à disposition seront connectés via un VPN léger et décentralisé (tinc, par exemple)
      • Une fois connectés, un système de container sera mis en place pour offrir une virtualisation légère
      • Ainsi, tous les membres du groupe disposeront d'un cloud personnel, de confiance, sur lequel ils pourront, eux-mêmes, déployer les services souhaités, à la disposition des membres du groupe.

      Ainsi, le projet n'a effectivement plus le moindre rapport, techniquement parlant, avec celui évoqué initialement. D'un produit fini, à destination de l'utilisateur final, nous avons maintenant un projet ouvert, orienté vers le social au-delà même du réseau (car se basant sur la collaboration d'amis, la répartition de tâches et de responsabilités, etc), non limité en ressources, et pouvant offrir une disponibilité plus grande (possibilité de failover, de balancing...).

      Je suis personnellement convaincu que cette nouvelle orientation est bien plus intéressante, et je vous demande donc votre avis sur son adoption, assorti de critiques nécessaires.

      5 comments (most recent: 1 year, 2 months)
    • Du nouveau sur votre cahier des charges ? | Oct. 10, 2010

      Bonjour,

      Je suis très heureux de retrouver ce type de projet dans vos pages, un hébergement de ses données à la maison, sur du hardware libre, ou au moins Open Sources, ce serait vraiment bien...

      Avez-vous pu avancer sur le cahier des charges ? Je vois que la page wiki dédiée est encore vide, avez-vous du nouveau en arrière boutique ?

      Je bricole de mon côté, malheureusement sans en avoir toutes les compétences pour le moment, un liveCD ou USB installable (Live Debian), avec la base d'un serveur LAMP. Le début des travaux se trouve ici : http://wikis.konnectif.net/machinbox/

      Si des bouts d'idées pouvaient intéresser quelques-uns, ou faire tiquer d'autres, ou amener à une discussion sur ce que devrait contenir une nobox, je suis partant et preneur ! Bonne journée, et à bientôt.

      6 comments (most recent: 1 year, 5 months)
    • Hardware potentiel | Nov. 2, 2010

      Have you seen the Excito B3 : http://www.excito.com/bubba/products/technical-specifications.html

       

      Seems pretty appropriate for this project. Should h:d add it to it's products? (no sale outside of sweden yet - deliverable though).

      See review here : http://www.phoronix.com/scan.php?page=article&item=excito_b3&num=1

       

    • Autre fonctionnalités | Sept. 24, 2010

      Quelques fonctions que j'aimerais voir dans la boîte:

      - Une gestion de signets/références type Delicious ou CiteULike

      - “Social backup” (peut-être même failover?) en utulisant les nœuds des amis topologiquement proches;

      - Et, soyons fou, un Home Agent pour supporter Mobile IPv6. Ainsi. non seulement la boîte est hébergée chez moi, mais même mes smart-phone(s) et autres laptotps en déplacement deviennent accessible à une adresse fixe au sein de mon propre préfixe. Et ça peut même remplir la fonction d'un VPN par la même occasion.

      2 comments (most recent: 1 year, 6 months)
    • FreedomBox sur le wiki Debian | Sept. 9, 2010 Un projet similaire semble vivre ici: http://wiki.debian.org/FreedomBox "Vision Statement We live in a world where our use of the network is mediated by organizations that often do not have our best interests at heart. By building software that does not rely on a central service, we can regain control and privacy. By keeping our data in our homes, we gain useful legal protections over it. By giving back power to the users over their networks and machines, we are returning the Internet to its intended peer-to-peer architecture. In order to bring about the new network order, it is paramount that it is easy to convert to it. The hardware it runs on must be cheap. The software it runs on must be easy to install and administrate by anybody. It must be easy to transition from existing services."
      1 comment (most recent: 1 year, 7 months)
    • Mise à jour DNS | Sept. 24, 2010

      Je lis dans la description courante des fonctionnalités prévues : “l sera alors intéressant de fournir un serveur centralisé faisant uniquement office d'annuaire, et offrant à chaque box un sous-domaine propre (avec certification via GPG), par exemple "login.nobox.tld". Une sorte de dynDNS.

       

      Bien que GPG semble adapaté pour la communication de personne à personne, je ne suis pas sûr qu'il soit judicieux de le généraliser pour des tâches automatiques entre machines. SSL (entre autres) pourrait être plus adapté. De plus, avoir des certificats valid(e|able)s est déjà nécessaire dans le cadre de certains services proposés pour la box (OpenID oui, mais je ne tape pas mon mot de passes sans HTTPS !).

      Sinon, il pourrait être intéressant de jeter un œil à l'IETF. La RFC3007 propose un standard pour des mises-à-jour dynamiques de nom de domaine.

    • OpenID | Sept. 14, 2010

      Je m'écarte un peu du sujet pour réagir à la fonctionnalité prévue «Fournisseur OpenID».

      Je ne soutiens pas OpenID pour une raison simple mais que j'ai mis longtemps à réaliser: ce protocole vous permet de vous identifier auprès du serveur mais en tant que lecteur vous ne pouvez pas savoir si un message a réellement été écrit par l'OpenID affiché car il n'y a ni cryptographie à clé publique pour signer le message ni possibilité standard d'authentification du message auprès du fournisseur. Donc n'importe qui peut vous faire dire n'importe quoi, certes vous pouvez contester, mais le mal aura probablement déjà été fait si vous en venez à ça.

      My 2 cents.

      3 comments (most recent: 1 year, 8 months)
    • OpenID | Sept. 14, 2010
      1 comment (most recent: 1 year, 8 months)
    • Fiabilité | Sept. 14, 2010


      2 comments (most recent: 1 year, 8 months)
    • Fiabilité | Sept. 14, 2010

      Je lis sur la page des fonctionnalités prévues:

      «C'est certainement le gros point noir du projet : on ne pourra pas avoir la fiabilité d'un datacenter»

      Je ne suis pas d'accord. Avec beaucoup de Soxyd et des propriétaires qui partagent de l'espace disque on peut avoir des sauvegardes et même géographiquement éloignés.

      Les données privées importantes sont stockées compréssées et découpées et/ou chiffrées, sur un service payant ou en P2P et/ou en F2F.

      Quant aux données publiques, on pourrait imaginer faire appel aux sauvegardes si le Soxyd propriétaire des données n'est pas connecté. Malheureusement le DNS et le web n'ont pas été conçus pour ça donc il ne sera pas possible de confier la recherche des sauvegardes au navigateur du client. Un serveur DNS prévu pour ça peut proposer une redirection au client - si une sauvegarde est disponible - en cas de défaillance. Le problème est de savoir quand c'est le cas. La seule solution que je connaisse est de pinger en régulièrement. Afin de ne pas surcharger le système central on peut utiliser un réseau en arbre/pyramide (chaque serveur est connecté à n serveurs) ou en anneau (chaque serveur a un numéro et est connecté à celui qui a le numéro attribué suivant). L'anneau pourrait aussi permettre de localiser rapidement une sauvegarde publique si le numéro d'un serveur détermine ce qu'il sauvegarde (en utilisant un hash de l'URL par exemple).

      Bref, on peut faire beaucoup de choses en P2P, le seul «problème» est que les protocoles et logiciels actuels n'ont pas été conçus pour.

    • Dans l'air du temps | May 4, 2010

      Dans le même ordre d'idée, et pour compléter la réflexion:

      •  http://www.framablog.org/index.php/post/2010/04/11/moglen-freedom-cloud
      • http://www.suna.fdn.fr/globenet/no-box/cahier-charges
      5 comments (most recent: 1 year, 8 months)
    • Tout est question d'IP | June 16, 2010

      J'ai reçu mon Sheeva il y a quelques jours, et, le temps d'y installer un système propre (la ubuntu de base est vraiment dégueulasse), je me penche sur des problématiques de connectivité : l'appareil sera dans la majorité des cas connecté dans un réseau local. On peut essayer de prendre la tête à l'utilisateur (n'oublions pas qu'on cherche à rendre le système très "user-friendly", et que l'utilisateur ne devrait idéalement pas avoir à toucher la conf de son routeur, ou quoi que ce soit d'autre que l'installeur soigné qu'on lui proposera. Une solution intéressante est de passer par l'IPV6 : Free propose par défaut un bloc /64, pas très stable mais suffisant pour nos besoins, mais il me semble qu'Orange traîne encore la patte à ce niveau.

      2 solutions donc pour un tel cas de figure :

       

      • le logiciel nobox gèrera les deux protocoles, et décidera de passer par l'IPV4 uniquement si c'est la seule option disponible, mais alors on devra emmerder l'utilisateur avec la redirection des ports etc, sans compter qu'on limitera la possibilité d'avoir d'autres serveurs dans le réseau local.
      • Encapsuler la connexion IPV4 dans un service comme Hurricane Electric, afin de bénéficier d'un bloc /48 stable et routable. Cette solution est intéressante dans le fait qu'elle s'applique à tout le monde, et permet de l'IPV6 propre et natif. Cela dit, il s'agit de faire confiance à un tiers supplémentaire, ce qui n'est pas forcément en corrélation avec l'esprit d'indépendance de Nobox. De plus, et bien plus embêtant, on ne peut pas automatiser cette procédure car il faut s'inscrire sur HE pour bénéficier de son encapsulation, ce qui est à éviter si possible.
        Je vois une troisième solution, basée sur la précédente : proposer "nous-mêmes" un service d'encapsulation IPV6. En profitant par exemple de la Férération FDN (plus d'infos ici : http://lacantine.ubicast.eu/videos/diy-isp-devenez-votre-propre-fournisseur-dacces-a-internet/ ), il serait techniquement possible d'offrir ce service. Resterait ensuite à l'automatiser pour les utilisateurs de Nobox (avec éventuellement une inscription comprise dans la phase d'installation/configuration du service), et réfléchir à un moyen de lever des fonds pour amortir le prix de la bande passante utilisée. Cette idée est assez risquée, et passablement brouillon, donc il y aura pas mal de choses à revoir et à réfléchir en profondeur.
      Evidemment, je suis complètement ouvert à d'autres idées que je n'aurais pas prévues.

       

      2 comments (most recent: 1 year, 8 months)
    • Nouveau nom | July 2, 2010

      Comme vous avez pu le constater, Nobox n'était pas une option convenable pour le choix définitif du projet (les domaines étant déjà réservés, entre autres). C'est pourquoi j'ai pris l'initiative de changer le nom (et de réserver les domaines associés). Nous travaillerons donc, sauf si quelqu'un a une meilleure idée, sur le projet Soxyd. Ce nom est une contraction à la base de "social seed".

    • Choix de logiciels | May 5, 2010

      Admettons que l'on travaille sur un SheevaPlug (ce qui sera certainement le cas en premier lieu au vu de la disponibilité du matériel). Ce thread a pour vocation de choisir les solutions logicielles les plus adaptées au projet.

      Système d'exploitation

      A titre personnel, et au vu de mon expérience, je propose de partir sur de la base de Gentoo GNU/Linux, pour profiter de sa souplesse et de sa facilité à modifier des éléments cœur du système. L'inconvénient qui saute alors aux yeux est la nécessité pour Portage d'avoir environ 500Mo de libre pour son arbre. Il faut répondre à cela qu'il n'est vraisemblablement pas nécessaire de syncroniser l'arbre total pour l'utilisateur, le système étant préinstallé (on connait le processeur, donc les paquets seront précompilés et optimisés pour cette architecture). Par la suite, l'utilisateur aura certainement opté pour une solution de stockage (utilisation du serveur oblige), ce qui autorisera le téléchargement de l'arbre Portage.

      6 comments (most recent: 1 year, 11 months)
    • Matériel | May 4, 2010

      L'idée initiale est venue avec la connaissance du SheevaPlug, un serveur miniature doté d'une prise. Son inconvénient principal est le faible espace de stockage interne (512Mo Flash), heureusement comblé par un port USB et un SD.

      Son grand frère, le GuruPlug, embarque la gestion du wifi et bluetooth, ainsi qu'un deuxième port USB dans sa version standard, et un ethernet et un sata en plus dans sa version "plus".

      Il semble également intéressant de se pencher vers du matériel capable de se connecter de lui-même, comme la Fonera, ou des routeurs ouverts.