company:gm

Il n’y a pas que l’alternative « tout chez big brother » ou « tout chez soi » ; une réponse coopérative serait sans doute plus adaptée. Ce n’est pas facile, il faut accepter de s’associer avec d’autres, faire circuler des ressources, prendre le risque de ne pas être d’accord…

#cccp #portabilité_des_données #alternc #debian

EDIT : j’ajoute que certains services qui semblent difficiles à gérer sont en fait faciles, et inversement. Le mail par exemple tourne rapidement au cauchemar quand il s’agit de lutte anti-spam (réception), de réputation de son IP (pour l’envoi), de gros volumes (stockage).

Oui, c’est comme la voiture, la machine à laver ou la perceuse. Plein de services peuvent (devraient) être mutualisés plutôt que d’avoir chacun le sien.

@RastaPopoulos Mauvaise comparaison : les objets physiques qui ne servent que de temps en temps et encombrent le reste du temps devraient être mutualisés. Pour le virtuel, c’est moins clair.

En tous cas @stephane fait bien de rappeler qu’on manque d’imagination et d’initiative

@Fil Je parlais de gens qui manquent de temps. La vie associative, c’est super, mais ce n’est pas un moyen de libérer du temps :-)

C’est un sujet sur lequel je me suis un peu penché. J’ai d’ailleurs personnellement commencé à m’extraire du giron de Google/Facebook... Je ne maîtrise pas encore tous les aspects, mais progressivement les plus essentiels migrent : messagerie électronique avec webmail (postfix + roundcube), blog (wordpress), stockage (owncloud).

Côté sécurité, toutes les données hébergées ne sont pas à vocation purement privée : par exemple, les messages du blog/site, les photos que l’on aurait hébergées sur Flickr, les vidéos de son chat sur Youtube...

Le chiffrement peut permettre de stocker des données chez un hébergeur tiers qui fournit du Cloud, mais pose problème pour l’échange de données. On aborde d’ailleurs une forme de DRM avec diffusion de clé.

Le cercle familial/amical est un bon espace de partage au sein duquel on peut imaginer facilement la mise en commun de ressources pour de l’auto-hébergement. J’emploie volontairement le terme de cercle car c’est une approche que je trouve judicieuse dans la définition d’un scope de partage.

Et si on parle de mutualisation de moyens, il faut être sensible à des technologies de type dé-duplication qui peuvent réduire la volumétrie.

Bref, je suis du métier et faire la glu entre tous les composants peut s’avérer complexe. Alors, je rejoins pleinement @Stéphane sur l’aspect simplicité pour que Mme. Michu puis s’auto-héberger ;)

c’est pourquoi je parle plus volontiers de #coopérative que d’association : si chacun traite indépendamment une partie du problème et que ça bénéficie à l’ensemble des autres, on gagne du #temps — si on passe son temps à se contredire et à se marcher sur les pieds, non…

Il manque à mon sens, une ligne « comment sauvegarder son nuage » avec une suggestion de solution > il n’y en a pas de simples hélas...
J’étudie à l’instant même Kolab. Même s’il ne suffit que d’un « apt-get » pour tout installer (une fois le bon dépôt configuré), euh... ensuite... pour tout configurer par l’interface web... il faut quelques connaissances... peu répandues.
Et je n’évoque même pas les soucis de sécurité, et de failles de sécurité. Joomla 1.5 a été déployé sur des milliers de sites, par des non-professionnels qui ne pensaient pas que ça pouvait faire l’objet de tant de soucis... et qu’il était impératif de mettre à jour vers une version récente du CMS...
D’où le côté incontournable des solutions « toutes en un », maintenance y-compris.
On en arrive alors à des réflexions sur le coopératif.

Bonjour, j’ai eu l’occasion de discuter récemment avec le créateur d’une start up française (très récente) qui veut selon ce que je comprend répondre à cette question. Je n’ai pas les compétences techniques pour juger si leurs solutions répondent en partie ou complétement à l’enjeu que vous soulevez, mais... peut-être à suivre ! :
►https://www.cozycloud.cc
j’aime assez leurs textes de blog : http://blog.cozycloud.cc

@mmemichu

et une étiquette #manque_de_temps

@geodelc CozyCloud semble très intéressant. Si je comprends bien, ils ont deux offres, une hébergée (du SaaS classique) et une où on s’auto-héberge. Le logiciel est libre, mais pas encore fini (« In the future there will be a fully packaged virtual machine », exactement ce que je suggérais dans mon article).

@stephane, ma comparaison avec des objets physiques encombrants a un sens, car elle partait entre autre d’une réflexion écologique. Si chacun a son serveur et héberge ses propres trucs, ça a certainement un impact écologique non négligeable, tout comme la voiture pour chaque foyer.

Sebsauvage a mis en place une page qui recense quelques projets : ►http://sebsauvage.net/auto

Il y a aussi : ►http://www.auto-hebergement.fr

@rastapopoulos tout le monde a déjà son serveur : la passerelle domestique (alias « box »). Le problème est que la majorité des gens n’en ont pas le contrôle.

@geodelc : je trouve aussi le projet intéressant. Par contre, je ne sais pas quels sont les retours sur la sécurité de Node.js sur lequel semble s’appuyer le produit. Ce n’est pas un début de troll, mais les nouvelles technologies n’ont pas toujours eu le temps de subir les assauts des vilains pirates (surface d’attaque trop faible). En même temps, Node.js est quand même pas mal utilisé, donc à tester dans une VM...
Merci pour le lien.

Les sauvegardes « cloud » ne me plaisent pas des masses : perte de contrôle, confidentialité à géométrie variable, incertitude sur pérennité des données.
En ce moment, je cherche une solution locale type NAS RAID1 pour bétonner au moins mes données contre des défaillances de HDD. Mais je pense qu’il me faudrait ajouter un HDD externe d’ultra-sauvegarde qui aurait pour vocation d’être mis à jour une ou deux fois par mois et serait stocké chez un tiers de confiance, le reste du temps.
Là, je pense que mes données commenceraient à moins craindre.

ya des vm en pre-build version qui font +ou- ça seulement niveau maintenance faut compter seulement sur toi...un truc totalement automatisé est utopiste (1 seul exemple : passer de lenny à squeeze ne se fait pas comme ça). Ou alors faut externaliser les données pour ne mettre à jour que le systeme mais là on en revient à faire du cloud :)

@monolecte : Quelle est la volumétrie des données que tu considères comme critique ? Certains pensent que leurs photos de vacances ne doivent pas être sauvegardées (pour bon nombre, ils changent d’avis quand leur disque lâche). Pour les petites volumétries, on peut imaginer une sorte de RAID sur différents fournisseurs de Cloud qui ne stockent que des données préalablement chiffrées. Plus il y a de fournisseurs, plus tu as de volumétrie ou de redondance. C’est un peu ce que fait symform (http://www.symform.com/our-solutions/key-features) sur les NAS de ses utilisateurs. Ensuite, il faut identifier le niveau de sécurité de chaque type de données pour appliquer la politique de sauvegarde idoine : les données qui ne bougent pas (photos déjà post-traitées, par exemple) peuvent être simplement archivées (éventuellement en plusieurs copies) à intervalle régulier et déposée chez un tiers de confiance à l’occasion d’un apéro, comme tu le suggères.

@tester1 : en fait, je pense qu’il faut garder comme axiome une séparation des données et de l’application/OS. En gros, tes données données doivent résider sur un espace qui n’est pas dépendant de l’application (filesystem dédié local ou distant, voire dans le nuage). Comme ça, lors de ta mise à jour, le risque sur tes données est plus faible : genre tu démontes le FS avant la mise à jour.

Le filesystem est secondaire : si tu « merdes » pour x raison et que le l’OS ne reboot pas, tes données sur patoche seront elles-aussi compromises. Pour assurer le coup il faudrait stocker les données/fichiers-de-config sur un second disque (un tiers de confiance revient à faire du cloud chez un autre prestataire...autant rester sur facebook & co) pour ne mettre à jour « que » l’image (mieux vaut dès le départ taper dans des mini distro hein :) ).

Bref faut investir quoi et s’y connaitre un minimum malgré tout...sans parler du coup inhérent à l’électricité, bande passante, machine dédiée (sinon ta ram et ton cpu en prennent un sacré coup dans la gueule -les gamers risquent de ne pas trop appécier-, etc etc).

@evenit : mon /home (≃ 40 Go), mes archives (≃ 300 Go), mes photos (≃ 200 Go). Donc, le cloud... pffff

ou si ne veux pas mettre les main dans le cambouie t’installes des trucs tout-fait sur window... :)

Ouais enfin sauf que l’objet de la discussion c’était justement d’avoir des outils tout-fait pour le grand public, sans mettre les mains dans le cambouis MAIS pas sous windows uniquement et en libre. Si on part du principe que d’office ce n’est que sous windows et en propriétaire qu’on peut avoir des outils simples à utiliser pour tous, on va pas aller loin...

@tester1 : Disons que tu as normalement possibilité de booter en mode rescue (depuis un CD ou une clé USB) pour accéder à ta partition. Je suppose que tu ne réinstalles pas dès que ça « merde » ;) Mais oui, il faut investir du temps et c’est bien là le sujet lancé par @stephane : qui a (dans l’ordre) le #temps, l’ #envie et la #compétence pour créer un produit simple, plein des fonctionnalités qu’attend Mme. Michu et qui fonctionne en auto-hébergement.

@monolecte : bon, bah ça va alors. Chez un fournisseur du type de hubic (sans publicité de ma part), tu as un stockage pseudo-illimité (maxi 100To) pour 120€/an. Tout dépend de la valeur que tu attribues à tes données... D’ailleurs, hubic est basé sur de l’OpenStack et il est prévu que l’API soit ouverte, donc les fans de cambouis pourront se tâcher.

@tester1 : quels « trucs tout-fait sous window » ?

@rastapopoulos L’argument écologique peut avoir un sens pour des serveurs physiques mais, aujourd’hui, quand on a un serveur dédié, c’est plutôt une machine virtuelle. Il y a donc une grande mutualisation.

@Fil Un très bon article en faveur de ces solutions coopératives ou associatives : http://blog-notes.jbfavre.org/?lautohebergement-ou-le-risque-de-lotohebergement,3034

dans le cahier des charges il est aussi stipulé que l’usine à gaz ne devrait souffrir d’aucun bug...donc demander à madame michu de faire de la récup de données en cas de pépin est d’une part contraire à ce qui est demandé et d’autre part légèrement « risqué » compte tenu du niveau des personnes ciblées.

Non franchement, gérer des serveurs n’a rien à voir avec du desktop...rien que pour cibler la machine il faut un domaine qui renvoie vers l’ip fixe/dynamique du gus et rien que pour envoyer des mail sur des serveurs comme gmail & co il faut des enregistrements dns spécifiques qui nécessitent des compétences avancées, etc etc.

non désolé mais c’est foireux ce projet...

@gastlag Non, ces deux pages Web décrivent une approche opposée, celle où on installe soi-même une par une les applications nécessaires (qui ne sont pas intégrées, chacun est gérée à part). Comme le dit l’auteur « amusant et instructif, pour les technophiles ». Pas du tout mon cahier des charges.

@evenit J’ai une connexion de poussin, donc, pas de cloud.

@tester Comme moi, justement, je fais de l’auto-hébergement à la main, je sais que cettte histoire d’enregistrements DNS spécifiques (lesquels ?) pour envoyer du courrier à Gmail est bidon. Cela n’empêche pas que gérer un serveur soit compliqué (cf. @Fil). Mais, justement, cela peut s’automatiser. L’absence d’argument (à part que Mme Michu est conne et le projet foireux) ne va pas aider à discuter.

« Bidon » ça dépend ce dont tu parles : moi je pars du principe que l’emission se fait à partir de son propre serveur mail (CAD sans passer par le smtp du fai) et dans ce cas gmail comme beaucoup d’autre demande d’abord à ce que l’émetteur posséde une ip fixe + des enregistrements dns de nature à identifier le serveur (dkim, spf etc) faute de quoi tes mails attérissent tous, dans le meilleur des cas, dans le dossier spam quand ils sont pas purement et simplement rejeté...

Pour le reste je me fais + l’avocat du diable qu’autre chose ;)

@stephane : merci pour le lien vers l’article d’@Fil. En effet, et c’était le sens d’un morceau d’un de mes commentaires, aujourd’hui l’auto-hébergement va s’orienter vers des solutions pour des cercles familiaux/amicaux/associatifs, bref des gens qui connaissent un ou plusieurs barbus qui fournissent un présence en ligne et gestion de données personnelles.

Pour ma part, je me suis lancé dans l’idée de fournir à mon cercle familial un système de sauvegarde en ligne sur les serveurs d’une société tierce qui me garantit un taux élevé de disponibilité des données contre quelques euros par mois. C’est d’ailleurs un aspect qu’il ne faut pas négliger : la qualité de service a un prix, mais il est distribué sur l’ensemble de la communauté qui utilise les ressources.

@tester1 : chez Gmail, ils aiment bien qu’on ait implémenté DMARC (SPF + DKIM). Cela permet de mieux passer le filtrage, mais ce n’est pas obligatoire. D’ailleurs, tant SPF que DKIM sont simples à implémenter. Là où ça se complique c’est si on veut signer ses enregistrements avec DNSSEC...

@tester1 Mais c’est faux. Purement et simplement. Je n’ai jamais mis d’enregistrement DKIM sur mes domaines et le courrier arrive bien à Gmail. (Compte-tenu du pourcentage de gens qui font du DKIM ou du SPF, Gmail n’accepterait pas grand’chose s’ils étaient aussi exigeants.)

Dans l’article de jbfavre (effectivement très clair), il manque à mon sens une notion : celle d’une portabilité (minimale) des données. Dès lors si un admin troll s’empare du serveur de mon asso pour y installer la version 3.14 de apache-ssl alors que je jure que par la version 3.13, je pourrai sans difficulté (et, dans l’idéal, d’un clic) transférer mes données vers le serveur de l’asso voisine, qui elle a bien compris que la 3.13 était mieux.

rsync over ssh suffirait largement à tous les besoins, surtout en considérant SMTP comme mort.

Et cela permettrait incidemment de se débarrasser des trucs de noubz genre p2p, et d’ambitionnner, enfin, un InternetFS citoyen.

Maintenant, je l’avoue, pour mon vieux papa qui comprend rien j’ai mis du Synology d’entrée de gamme @home : ça fait tout, bien, et c’est même pas trop propriétaire.

@stephane : et le serveur est chez toi (sous-entendu ton fai perso) ou sur un dédié ? Parce qu’ils ont des bases pour identifier/sélectionner les ip...bon après ya une histoire de whitelist mais au départ t’es blacklisté pour répondre à des critères d’exigences...sinon c’est spam à gogo ;)

Mince, exactement l’article que je voulais écrire (ce qui est assez rassurant !).

Plus sérieusement, c’est effectivement exactement ce qui me semble être la bonne solution. C’est important de rendre tout ça simple, donc oui pourquoi pas une image « disque », et comme déjà dit une WebUI qui permette l’administration, la navigation, etc dans l’ensemble.
Idéalement, je pense que l’on gagnerait même en une interface qui soit la plus KISS possible et qui propose une sorte d’API rudimentaire. Ainsi, nombre de solutions existantes pourraient venir se plugger dessus d’elles-même. Ça permettrait de pouvoir choisir le service que l’on souhaite parmi plusieurs alternatives (ce qui me semble être un gros point faible d’OwnCloud qui finalement réenferme l’utilisateur dans des choix qui n’ont pas été les siens (pas du tout dans les même proportions que Google bien entendu, et surtout pas avec les mêmes intentions)). YunoHost est à ce titre très intéressant comme projet !

Sinon, à titre personnel j’expérimente l’auto-hébergement sur mon Raspberry Pi (et justement j’ai codé en quelques lignes un genre de portail web rudimentaire (et adapté à mes besoins) pour unifier le tout). Voilà ce qui tourne H24 depuis quelques mois maintenant :
– Un webmail : Roundcube (mais c’est pas terrible, c’est lourd et ça manque de fonctions essentielles. C’est là qu’on voit que Gmail est très puissant... Je vais essayer SquirrelMail → http://squirrelmail.org ). Mon serveur mail reste pour le moment chez OVH (novice en linux, j’ai pas encore osé me lancer... j’attends un article de @stephane ;).
– Un lecteur RSS : Tiny Tiny RSS (excellent et très puissant : filtres automatiques, labels, application mobile, plugins, etc. je conseille vivement !) → ►http://tt-rss.org
– Un agenda : AgenDAV pour l’accès web (RAS, très bon → http://agendav.org ) couplé au moteur de calendrier DAViCal (la référence, super, je l’ai oublié ! Il gère aussi les carnets d’adresse, mais pas encore testé → http://www.davical.org ).
– Un gestionnaire de photos : PhotoShow (très bien, fonctionne sans base de données, uniquement via l’arborescence des répertoires/fichiers ce qui est pratique pour envoyer automatiquement des photos depuis android par exemple) → ►http://www.photoshow-gallery.com
– Un blog : PluXML (pas de bdd, uniquement un jeu de fichiers XML) → http://www.pluxml.org
– Un serveur XMPP : Prosody (RAS jusqu’à maintenant...) → http://prosody.im
– Un serveur SMB pour les fichiers (pratique...)
– Bien sûr un serveur web : lighttpd (super ! → http://www.lighttpd.net ) avec PHP évidemment.
– et avec un analyseur de statistiques via les logs de lighttpd : awstats (dont je me sert pas vraiment mais qui est complet et qui évite d’ennuyer les visiteurs avec du javascript...) → http://awstats.sourceforge.net
– Un SGBD : PostgreSQL
– Bittorent avec transmission (avec des applications desktop, mobile ou WebUI pour le gérer à distance : génial → http://www.transmissionbt.com/resources ).
– Un serveur pour lire ma musique : MPD (extra...) → http://fr.wikipedia.org/wiki/Music_Player_Daemon
– Un serveur VPN : OpenVPN (je fais pas toujours confiance aux hotspots wifi auxquels je me connecte occasionnellement (ni à la 3G...), ça me rassure un peu) → http://shadowblog.fr/7-vpn-sur-raspberry-pi
– Un serveur son sur lequel je stream le son de mon PC : PulseAudio/Alsa.
– Et cron qui me sert de réveil matin en lançant France Culture ;-)
– J’ai même branché une imprimante thermique (sans encre) pour imprimer des notifications (emails, twitter, etc.) sur des tickets de caisse... → https://www.adafruit.com/products/597

Le tout est sauvegardé via rsync sur une partition différente (du même disque...) toutes les nuits. Il faut soit que j’ajoute un disque soit que j’envoie sur Hubic (par exemple) après chiffrement.

Je n’y aurais jamais cru mais tout ça tourne sans difficultés et en simultané, sur un simple Raspberry. Je sais pas si je peux le pousser encore mais pour le moment la seule limite que j’observe est bien entendu ma maigre bande passante sur simple aDSL (et donc surtout en up)...

Plus généralement, ce que j’observe c’est que c’est effectivement incroyablement chronophage ! Ensuite, c’est une responsabilité parfois un angoissante... Quand ça marche pas, il suffit pas d’attendre. Il faut trouver et corriger. Et si je fais une erreur, j’ai plus de service. Et si j’ai pas le temps de corriger, ben j’ai plus de service pendant une semaine. Enfin, c’est pas encore arrivé...
Mais c’est aussi incommensurablement formateur (ce qui n’est pas un argument pour tout le monde) ! Et puis c’est agréable de constater qu’il y a des alternatives libres pour tout les usages que j’avais des services « cloud », au moins aussi puissantes (sauf pour le webmail où je cherche encore) et dans tout les cas personnalisables à souhaits. Je ne retournerai pour rien au monde sur Google Music et encore moins sur Google Reader (plus possible de toute manière me direz vous, mais pas plus chez feedly ou autre) !
Il reste par contre à travailler le design, c’est souvent pas sexy du tout...

Bref, au vu entre autre des commentaires, il semble y avoir du monde qui bidouille dans son coin et @stephane a raison, il serait effectivement temps de coordonner tout ça...

Bonjour chez vous.

Affaire à suivre ...

Concernant la partie serveur et gestion autonome des zones, je peux toujours proposer la solution que j’ai rapidement monté -mais pas encore finalisée- : http://greatns.com qui permet au « quidam » de pouvoir utiliser gratuitement un de mes serveurs secondaires gratuitement.

Effectivement, on peut arguer qu’il y à un objectif commercial derrière un tel système, mais je l’énonce clairement.

Qcq précisions sur ►https://www.CozyCloud.cc, puisque notre site n’explique pas encore tout ça :-)

1/ Pourquoi ?
Le web se “cloudifie”, pour le meilleur - ubiquité des services, simplicité, sécurité, interactions avec les terminaux mobiles - et le pire : nos données sont dispersées dans des silos étanches contrôlés par des quasi monopoles qui vivent de leur analyse et revente.

2/ Solution ?
Le pouvoir est du côté sur serveur (http://blog.cozycloud.cc/mantra/2013/01/19/server-side-is-where-the-power-lies), il faut auto héberger ses données et web app qui accèdent à nos données

3/ C’est une utopie
L’auto hébergement est une utopie de la même façon qu’avoir un Personal Computer l’était il y a 30 ans. Notre objectif est d’être l’iOs des serveur, l’ouverture en plus.

4/ La confidentialité ne sensibilise pas Mme Michu :
a) l’intérêt de l’auto hébergement ne réside pas que dans la confidentialité, loin de là : Réunir ses données permet des mashup aujourd’hui impossibles (alors meme que l’intégration est à la source du succès des écosystèmes fermés...).
b) madame michu évolue, demandez lui plutôt que de présupposer.

5/ vous n’êtes qu’une distro linux de plus ?
Pour nous un "serveur" est un chef d’orchestre de services, pas un kernel. Cozy est un PaaS personnel qui à la demande de l’utilisateur, via une chouette ui, peut installer ou supprimer une web app, laquelle peut être en Node.js, mais bientot aussi Python ou Ruby.

6/ En quoi facilitez vous les mashup de données ?
La persistance est mutualisée dans une web app, le datasystem, que les web app requêtent en REST (si elles y sont autorisées). Toutes les apps peuvent donc partager des données (mails, contacts, photo, agenda...) tout en laissant l’utilisateur contrôler qui accède à quoi.

7/ vous en êtes où ?
On bosse comme des ânes, on vient de démarrer une béta privée avec nos premières applications, suivez nous sur notre blog ou twitter pour avoir des news sur les nouvelles releases.

8/ Vous avez besoin de quoi ?
De feed back !
Donnez nous votre avis, tant sur les plans techniques que fonctionnels qu’ergonomiques etc...
Contactez nous, par mail ou irc, on sera content de réfléchir avec vous !

@evenit : en effet node est jeune, mais sa surface d’exposition est en croissance exponentielle. Et puis ce jeunot s’appuie sur du code de géants (librairies réseaux et moteur js V8 de Chrome...).
Au niveau de la sécurité on a (comme les autres :-) beaucoup de travail, toute remarque et conseil est bienvenu !

9/ vas te faire enculer.

désolé, c’est parti spontanément...du fond du coeur ;)
désolé...

@tester : je n’aimerai pas avoir ton cœur, je te plains sincèrement.

je m’excuse !!!

edit : allez demain je teste ;)

ok dak, que celui qui n’a pas déjà regretté un clic trop rapide jette le premier point godwin !

Ceci dit j’ai faillit répondre avec un « tu sais où tu peux te les carrer, tes excuses ? », que je trouvais très drôle mais j’ai douté sur ma capacité à expliquer que c’était VRAIMENT une blague, alors du coup je me suis abstenu. Couille molle sur ce coup là Ben...

c’est un joke ? Tu m’as abusé benjamin...

@monolecte Les volumétries (surprenantes) que tu donnes sont proches de celles données pour mon cher papa évoqué plus haut. Je persiste à penser que le DSM4.1 de chez Synology, donc, en hébergement matériel à domicile, est ce qu’il y a de mieux dans ce genre de cas même si ça n’est pas réellement libre (ça reste basé sur du libre et maintenu par une PME chinoise qui n’a pas besoin de se faire racheter).

@tester : sous « sign in », il y a un lien « démo ».
Je te laisse deviner vers quoi il mène.
Malgré les noms d’oiseaux qui ont volés cette nuit, merci pour ce retour, nous rajouterons ce lien à notre mail d’enregistrement à la béta. Les noms d’oiseaux étaient ils nécessaires ?

@benjamin1 : je trouve que Node.js apporte une touche de fraicheur dans le monde du web. Je jouais juste au vieux ;) J’ai regardé un peu ce qui se faisait et l’écosystème grossit rapidement...

Et sinon, en 10/, je verrais bien un lien vers un tutoriel pour l’installer sur sa propre machine. Ou alors j’ai juste mal cherché ;)

Bonjour,

Juste une petite idée comme ça, à propos du DNS secondaire. C’est effectivement bien d’en avoir un sur un deuxième AS (comme mentionné par ZoneCheck), mais si on part sur l’idée d’un paquetage utilisé par plusieurs personnes pour faire de l’auto-hébergement, pourquoi ne pas compter sur les autres ?
Une petite interface du style : « DNS secondaire hébergé par » avec un identifiant d’auto-hébergement à rentrer, et cette personne tierce (de confiance) devra accepter l’invitation.

Plus il y a de tiers, plus la résilience sera grande.

@glandos> la question de la résilience du serveur dns secondaire est à prendre avec précaution tout de même ... le principe du serveur auto-hébergé sur lequel tu es le seul à te soucier qu’il est up ou pas à ce moment ne s’applique plus si tu acceptes sur ton serveur de prendre la responsabilité d’héberger la zone d’un tiers qui lui s’en fiche éventuellement moins

@glandos @b3nj : mais dans le cadre d’un système coopératif/associatif, il est probable que le serveur ait un bon uptime. Et rien n’empêche de multiplier les serveurs secondaires au sein de son réseau : si chacun des participants au sein d’un groupe est secondaire pour l’ensemble des autres membres du groupe, le maillage devient suffisant pour assurer la disponibilité du DNS.

@glandos @evenit > il n’empêche la notion de suffisance est toute relative et il convient alors lorsque tu souscris à une telle approche coopérative/associative de bien être conscient de la probabilité de l’indisponibilité et de fait de l’abscence de possibilité d’établir un SLA viable.

@b3nj @evenit > En même temps, si tous les enregistrements DNS pointent sur la machine qui fait l’auto-hébergement, alors quand le DNS tombe, c’est que le reste aussi (normalement). Ce ne sera pas forcément le cas (on peut avoir des MX secondaires par exemple), mais ça limite la casse.
Sinon, la question de la confiance est quand même assez facile à résoudre. Par exemple, mes voisins me donnent leur clés de chez eux en cas de problèmes, ou bien s’ils sont en vacances. Ils me font confiance parce que je les connais. Je pense que les DNS ne devraient pas poser de problème, s’il y a déjà cette confiance…

L’auto-hébergement est fondamentalement inadapté aux protocoles comme le DNS, HTTP, XMPP, IRC, car ils sont conçus pour fonctionner avec des serveurs qui tournent en permanence. L’auto-hébergement a besoin de protocoles moins « centralisés », plus résilients, qui répartissent les données et la charge de travail. Bref il a besoin d’Internet, hors aujourd’hui on a beaucoup de Minitel.

@evenit : en fait on a 2 tuto, mais il faudrait qu’on rende plus compréhensibles nos liens. Les voici :
– pour installer un environnement de dev : http://blog.cozycloud.cc/tutorial/2013/02/28/how-to-quickly-start-a-personal-web-app-with-nodejs-and-cozy-cloud
– un pour installer un cozy complet sur une machine (uniquement partie Getting ready in 5 mn) : https://github.com/mycozycloud/cozy-setup/wiki/Setup-cozy-cloud-development-environment-via-a-virtual-machine

L’environnement de dev est plus simple à mettre en place car on packagé pas mal de choses dans une vm.

Pour ce qui est de s’installer un cozy complet pour l’auto héberger, le second tuto sera beaucoup plus facile quand on aura également packagé l’ensemble dans une vm : c’est au programmes des 2 prochains mois.

@Changaco : pas du tout d’accord. D’abord, comme indiqué plusieurs fois, on ne parle pas de 100 % de succès. Il ne s’agit pas d’héberger Amazon.com ! Ensuite, l’auto-hébergement, aussi bien à la maison que chez un fournisseur IaaS, atteint des scores d’uptime tout à fait honorables (le record de mon Raspberry Pi à la maison est de 21 jours et encore il a repris le service tout de suite après son débranchement).

@glandos Oui, excellente idée, et ça va dans le sens coopératif/associatif souhaité par @Fil.

@b3nj SLA ? Eh, on parle d’auto-hébergement de particuliers ! Je suis tout à fait d’accord avec @evenit sur ce point.

@benjamin1 : merci pour les liens. Je jetterai un œil quand je trouverai un peu de temps de cerveau libre ;)

@glandos @stephane : on peut aussi imaginer matérialiser la confiance via des clés PGP puisqu’il est aussi possible d’attribuer un degré de confiance. Et comme la base de PGP est l’échange de clés entre individus qui se rencontrent pour de vrai, cela peut recouper le cercle familial/amical/associatif. Reste à trouver un moyen simple et rigolo de faire l’échange avec des gens non techniciens autour d’un apéro.

Cette mode du « tout par moi même », n’en finit pas de m’étonner. Je comprends que le Raspberry, l’Arduino fasse rêver, mais il y a des limites. Je comprends l’enjeu de sécurité et de contrôle de sa vie privé, mais bon on parle d’héberger chez soi des dizaines de service informatique, du FTP, du HTTP, du mail, de la sauvegarde, etc...

Dans les sociétés, c’est un métier en tant que tel, parce qu’il ne faut pas qu’installer, paramétrer, mais aussi réagir en cas de pépin. Au final, vous comptez mettre madame Michu à faire du Linux ? Perso, je suis développeur, et il y a bien longtemps que je n’installe plus de distro linux pour le fun, donc je pense qu’une personne non informaticienne, sera encore plus réticente.

Prenez l’administration d’un Synology, et autant c’est clair, autant le nombre de choix peut faire fuir le quidam. Et je ne vous raconte pas en cas de problème. La solution IaaS est pour moi la plus crédible des solutions. Qu’au moins, le physique soit géré par des personnes qualifiées et motivées.

@pom421 : à mon avis un développeur mainfraim sur cartes perforées devait dire la même chose il y a 30 ans.

Attention, je ne suis pas ironique, je veux juste dire que nous sommes loin d’avoir terminé la course aux couches d’abstractions en informatique. Et ce sont ces abstractions qui permettent de mettre toujours plus de complexité à la disposition de tout à chacun (y compris de nous autres techniciens).

Je pense qu’aujourd’hui tout est réuni pour rendre assez facilement possible cette couche d’abstraction au dessus de linux pour que madame michu l’utilise (ce qui est d’’ailleurs déjà le cas via sa box ADSL, son smart phone ou son cadre photo numérique).

@stephane En fait, c’est déjà ce que je fais aujourd’hui, j’ai mon DNS primaire chez moi (nsd3), et j’ai le secondaire hébergé par un ami qui a son DNS sur une machine en location chez OVH.

Par contre, je dois reconnaître qu’on est très loin de la simplicité. Très très loin. J’essaie parfois d’expliquer ce qu’est le DNS (très grossièrement), mais ce n’est pas évident.

@Fil Un projet qui semble tout à fait convenir à ta démarche coopérative : partage de matériel http://the.re

Mes fiches de paie papier (comme tout le reste de la paperasse qui me donne une existence de citoyen), je les conserve chez moi. C’est chez moi, c’est privé, c’est moi qui décide ce que j’en fais, c’est garanti par un certain nombre de lois, et cette garantie est au final liée à la souveraineté de l’État sur l’espace physique qu’occupe mon chez-moi (quant à mes scans de fichie de paie, tant qu’ils restent sur mon disque dur chez moi, c’est la même chose).

Maintenant je voudrais bien virtualiser ces scans et les placer
dans un chez moi virtualisé (un cloud à moi) et obtenir pour ce chez moi les mêmes garanties que celles que l’État donne à mon chez moi physique.

Bon il faut tirer les fils pour voir où ça mène, je suis pas juriste
pour 2 sous, mais au bout il doit y avoir l’affirmation par l’État
de sa souveraineté sur un espace numérique garantissant aux habitants citoyens les mêmes droits que ceux liés à leur espace physique.

@françois1 : Le fait d’être « chez soi » n’est pas suffisant pour établir la valeur de preuve d’un document, numérique ou comme physique.
Et dans le cas du numérique, c’est meme l’inverse : si le fichier n’existe que chez toi, il n’aura qu’une faible valeur probante.

Je ne suis pas non plus juriste, mais voici qcq info pour expliquer ça :

1/ un document n’est jamais une preuve absolue : les juristes parlent de preuves établies sur la base d’un « faisceaux de présomptions ». Un document, celons sa constitution, sera donc un élément plus ou moins probant.

2/ La falsification est toujours possible, meme pour un papier, c’est pourquoi un document physique, même présenté comme un « original », ne sera pas forcément retenue comme étant une « preuve » absolue. C’est pour ça qu’il faut des éléments rendant la falsification moins probables : signatures, paraphes en bas de pages, tampons, papiers à filigrannes produits celon des techniques maitrisées que par 1 producteur (billets de banque par ex) etc...

3/ la falsification numérique d’un document numérique étant extrêmement facile, la « valeur de preuve » d’un fichier est moindre, mais pas nulle. Si dans la recherche de preuve il n’y a rien à opposer au fichier, alors il sera pris en compte par la justice.

4/ c’est pour ça qu’il y a des tiers de confiance qui proposent un « stockage à valeur probant » (le plus connu en fr étant Arkhineo, filiale de la caisse des dépots et consignation). Il s’agit d’un tiers qui conserve un hash d’un document lui permettant de certifier qu’un fichier qu’on lui présente pour authentification qcq années après son émission est bien celui qui lui a été remis à l’origine e par tel ou tel tiers.

Donc pour posséder une version numérique d’un document ayant une valeur probante significative, il faut que celui ci ait été dès le départ au format numérique et que l’organisme qui l’a produit le transmette à un tiers de confiance proposant un stockage probant, le tout en respectant bien sur une série de normes.

Une autre solution serait la numérisation à valeur probante pour envoi certifié à un tiers de confiance (un peu comme la photocopie certifiée conforme à la mairie), mais je ne sais pas si un tel service existe.

Pour info la mise en place d’un stockage à valeur probante est un objectif pour Cozy Cloud et on regarde à faire ça avec la poste (mais honnêtement on est à une phase très prospective sur ce point)

En tout cas moi aussi je rêve de dématérialiser toute ma paperasse, le mouvement est en cours, mais ça va prendre encore un peu de temps....

@benjamin1 : je ne parlais pas tant de l’authenticité des éventuels documents virtualisés que de la protection de l’accès à ces documents, de la garantie que je suis le seul à décider de ce qu’il advient d’eux, ce qui est le cas pour mes documents papier, fussent-ils des faux grossiers. Le problème de l’authentification est un des éléments de l’équation mais ce n’est qu’un des éléments techniques (technique au sens large) à gérer en cas de besoin pour la section administrative de mes documents virtuels.

Il me semble que l’essentiel des questions préliminaires qu’on veut régler quand on envisage de se « cloudifier », c’est celui du statut et de la propriété de ce qu’on envoie dans le nuage. En tous cas en ce qui me concerne, c’est le principal facteur qui limite pour le moment ma virtualisation à mes supports physiques personnels : c’est carrément nul en terme de disponibilité et d’accessibilité, mais en terme de protection et de confidentialité aucune solution à ma connaissance n’est à l’heure actuelle en mesure de m’assurer une garantie équivalente. Et c’est bien la motivation principale du post initial de Stéphane Bortzmeyer.

Si je fais héberger dans le cloud une instance numérique de ma feuille de paie*, en louant un espace à un prestataire, je ne veux le faire que si j’ai la garantie absolue de pouvoir tout récupérer quoiqu’il arrive (sauf catastrophe majeure). En gros, j’exige que le propriétaire de l’appartement que je loue ne fouille pas dans mon appartement dans mon dos et me laisse tout récupérer à l’échéance du bail, quelqu’en soit la raison.

Analogie qui est le point de départ de l’idée de la souveraineté de l’État sur un territoire numérique, parce que c’est elle qui assure l’inviolabilité de mon domicile dans les nuages.

* (je fais pas une fixette sur la feuille de paie, c’est évidemment valable pour tout le reste, photos, emails, etc..., mais la fiche de paie a besoin de pérennité, de disponibilité, de confidentialité, voire d’authentification, donc c’est un bon résumé des spécifications cloudesques)

I’d assumed that GM would increase the use of chemicals. It turned out that pest-resistant cotton and maize needed less insecticide.

#lol quoi, le but c’est de faire synthétiser peu ou prou les mêmes molécules par les plantes elles-mêmes, donc forcément qu’il y a moins besoin d’intrants extérieurs ! Au final ya toujours les mêmes pesticides dedans...

Dans plusieurs reportages sur l’agriculture associée (planter arbres / fleurs / légumes complémentaires ensemble) utilisée dans des productions notamment en inde, on explique qu’à l’inverse, les OGM auraient du limiter l’usage de pesticide, mais ça ne fonctionne pas. Avec les maladies et plantes résistantes comme l’amarante qui ont fait leur apparition, ce serait encore pire. En inde, il y aurait des suicides de producteurs qui ne peuvent plus payer les semences et les pesticides nécessaires... Je crois plus volontiers ces gens là, qui n’ont pas d’intérêt financier à défendre un produit, puisqu’ils défendent l’absence de produit.

#alimentation

Ne faudrait il pas plutôt titrer : L’alliance de Peugeot avec GM est-elle la cause de ses ennuis actuels ?

@rumor : toi aussi, ça t’a chagriné ? La première phrase de l’article est exemplaire :

La République islamique est-elle responsable des maux que connaît actuellement PSA ?

si c’est Le Point qui le dit alors...

aussi cet article
http://seenthis.net/messages/70280

http://vimeo.com/43879272#at=0

#mercenaires

on a aussi un commentaire en français ici
http://www.combat-monsanto.org/spip.php?article917

Pour faire avancer sa cause, le lobby des OGM cherche à recruter des personnalités. C’est ce qui ressort d’un brouillon de courrier, « strictement confidentiel », que Rue89 s’est procuré, ainsi que The Guardian. Il dévoile les grosses ficelles qu’utilise le lobby pour répandre sa bonne parole, jusqu’aux décideurs de la Commission européenne.

EuropaBio a besoin d’obtenir des autorisations de Bruxelles. Mais, selon l’association européenne des biotechnologies, l’Union européenne n’a pas assez déverrouillé l’exploitation des cultures génétiquement modifiées.