GuiGui's Show

« À mesure que nos vies sont de plus en plus connectées, les données personnelles que nous émettons lors de chacune de nos activités deviennent un enjeu industriel considérable. Partons à la découverte d’un monde bâti autour du big data. »

Une petite introduction bien formulée sur le traitement massif des données personnelles que nous donnons au quotidien par des entreprises et les conséquences de tels traitements (contrats d'assurance personnalisés, prédiction du risque d'accord ou non d'un crédit bancaire, affinement des arguments lors d'élections, ...).

Via #ldn sur geeknode.

J'ai utilisé cet outil récemment. Mon avis :
    + C'est pratique, notamment pour obtenir un résultat qui nécessiterait un enchaînement de commandes UNIX complexes ;

    + Du coup, c'est super pratique pour quelqu'un qui n'est pas à l'aise avec les commandes UNIX bien connues ou qui n'arrive pas à conceptualiser l'obtention d'un résultat avec celles-ci alors qu'il y arrive parfaitement en SQL ;

    + J'aime [le] q ? Dat argument, right ? ;

    - On peut réaliser les mêmes traitements avec les commandes UNIX bien connues, en beaucoup plus rapide. Exemple un simple comptage du nombre de lignes : wc -l : 0m0.032s versus select count() : 0m22.848s sur un fichier de 1014083 lignes ; L'écart se creuse sur des requêtes plus complexes. Exemple : pour trouver des valeurs en commun dans une seule colonne de deux fichiers, 0m3.358s pour les commandes UNIX versus 0m56.159s pour q, toujours sur un fichier de 1014083 lignes ;

    - Il faut déjà avoir un fichier au format "CSV" (au sens large, bien organisé, colonnes, séparateur unique, ...), ce qui n'est pas toujours le cas et ce qui nécessite donc un pré-traitement avec ... les commandes UNIX bien connues.

Via http://korben.info/utiliser-la-syntaxe-sql-sur-des-fichiers-csv.html

« Interrogé, le juge Bermúdez répond: “Je n’enquête pas sur des faits spécifiques, j’enquête sur l’organisation, et le danger qu’ils peuvent représenter à l’avenir” 1; créant ainsi un nouvel exemple d’arrestation préventive.

[...]

Les motifs présentés par le juge pour leur incarcération sont la détention de certains livres, “la production de publications et de moyens de communication”, et le fait que les accusé·es “utilisent les emails avec des mesures de sécurité extrêmes, comme les serveurs RISE UP” 2.

[...]

Riseup, comme d’autres fournisseurs de courrier électronique, a l’obligation de protéger la confidentialité de ses utilisateurs et utilisatrices. Beaucoup des “mesures de sécurité extrêmes” utilisées par Riesup sont de bonnes pratiques communément admises en termes de sécurité sur Internet et sont aussi utilisées par des fournisseurs de services comme hotmail, GMail ou Facebook. Toutefois, contrairement à ces fournisseurs, Riseup ne veut pas permettre la mise en place de portes dérobées illégales, ni vendre les données de ses utilisateurs et utilisatrices à des tierces parties.

Le rapport du parlement européen sur le programme de surveillance de la NSA “souligne que le respect de la vie privée n’est pas un droit de luxe, mais constitue la pierre angulaire d’une société libre et démocratique” 3. Des révélations récentes sur l’étendue des violations de la vie privée par les États montrent que tout ce qui peut être épié le sera 4. De plus, nous savons que la criminalisation de l’usage des outils de protection de la vie privée a un effet dissuasif sur toutes et tous, en particulier les défenseurs des droits humains, les journalistes et les activistes. Abandonner ses droits fondamentaux à la vie privée par peur d’être identifié·e comme terroriste est inacceptable. »

Bonne analyse de Korben sur les objets connectés, à lire.

« C'est de la domotique qui se veut naturelle pour l'utilisateur et qui transforme la maison en maison intelligente qui s’adapte à vous, à vos goûts, à votre état...etc. Par exemple, si vous avez froid, votre fauteuil activera la fonction chauffage automatiquement. Si vous rentrez chez vous, le MP3 sur les oreilles, en enlevant votre casque, la musique sera jouée automatiquement sur vos enceintes de salon...etc etc.

[...]

Ils ont pas mal insisté sur l'aspect ouvert de leur truc mais au final, c'est loin d'un consortium de fabriquant bossant sur une norme libre. Non, c'est juste une technologie propriétaire Samsung que les autres vont pouvoir utiliser au travers d'un SDK et d'API.

[...]

Ce qu'il faut bien comprendre, c'est que pour que toutes ces technos fonctionnent en harmonie et soient agréables pour l'utilisateur, il faut que nous, en tant qu'être humains, soyons totalement profilé, et totalement transparents pour la machine.

Et par conséquent pour les sociétés qui développent ces machines. Ca va de simples comportements comme rentrer chez soi, ou enlever son casque audio, à des choses un peu plus précises comme nos habitudes de sommeil, nos absences, les pièces où nous sommes et à quel moment nous y sommes.. A nos goûts, tel que la musique que nous apprécions, le type de films que nous regardons, ce que nous buvons et nous mangeons...etc pour terminer enfin sur nos données physiques. Savoir si nous sommes en forme, ou malade ou fatigué après une grosse journée ou si nous faisons du sport et en quelle quantité...etc.

    Comportements immédiats
    Habitudes
    Goûts
    Paramètres physiques

Tout ça c'est ce qui nous caractérise. Et tout ça, sera utilisé par votre maison. Ce qui est cool en soi, car c'est votre maison et elle sera plus agréable à vivre.

Mais ensuite, BK Yoon a dé-zoomé sa "Big Picture" nous montrant des maisons connectées entre elles, aboutissant sur des Smart Cities, puis sur des états, des pays et le monde entier connecté.

[...]

On peut tout imaginer... Aussi bien dans le confort pour nous rendre la vie plus simple et plus agréable que dans la "surveillance" globale de qui nous sommes.

Samsung bien évidemment traite uniquement du sujet du confort... "On va changer vos vies", ce sera "AWESOME" comme ils disent ici ! Mais de l'autre côté, ce dont ils parlent mais à demi-mot, c'est qu'ensuite, les gouvernements mais surtout les entreprises privées pourront exploiter ces données pour gagner de l'argent en connaissant nos habitudes, nos goûts, nos caractéristiques physique.

Je parle de pub mais aussi de recommandation de contenu. Un peu comme quand on fait une recherche sur Google, cette recherche est établie dans un contexte qui nous correspond. Le souci, c'est que ça laisse peu de place à la découverte spontanée et à l'élargissement des horizons.

[...]

Cet Internet des Objets, cette Smart Home, c'est génial pour les technophiles que nous sommes. Sérieusement, moi j'adore. Mais très flippant en tant qu'être humain. Nous allons être qualifié de manière très fine et derrière ces données seront d'abord exploitées commercialement puis pourquoi pas ensuite par les institutions officielles

[...]

C'est le futur.

D'après Samsung c'est même déjà le présent. Et ne pensez pas résister car on vous l'imposera... Vous ne voulez pas porter de bracelet connecté ou connecter votre voiture ? Pas grave, mais on refusera de vous assurer.

On ne pourra pas y échapper. Et je suis certain qu'on fera les mêmes erreurs qu'on a faites avec Facebook, Gmail, le cloud...etc, en confiant nos données les plus intimes à n'importe qui, sous prétexte que la vie est beaucoup plus facile parce que la cafetière s'allume toute seule ou que la serrure se ferme automatiquement le soir.

J'aime vraiment la technologie et tout ce qui se passe en ce moment est très grisant. Mais j'ai la certitude que cette technologie sera très vite détournée pour nous fliquer, nous faire consommer et nous asservir encore un petit peu plus. »

Raisonnement qui comporte quelques erreurs/vices (mails transitant via gmail cryptés -> erreur de terminologie et hors sujet puisque Google possède la clé privée ; mauvais argument, je pense quand l'on parle de l'échec des commentaires notamment sur les journaux politique : la qualité desdits commentaires, c'est une question de temps et d'éducation, de formation à l'expression en public à l'écrit) mais globalement bon et intéressant : la route est encore longue (surveillance, monopole, qualité de l'expression, ...) mais on a déjà fait du chemin.

« Second préjugé, celui qui concerne les codes de communication, et l’idée que sur Internet, on parle sans filtre. C’est une question compliquée.

On dit souvent de la communication sur Internet qu’il s’agit d’une communication écrite qui reproduit certains traits de la communication orale, une communication qui passe par l’écrit, donc, mais sans les rigueurs de l’écrit en termes d’argumentation, de niveau langue, de syntaxe etc. Oui, certes. Mais il faut ajouter que la communication sur Internet reproduit ces élements de la parole qu’on appelle « phatiques » – tous ces mots comme « Allô », qui n’apportent pas d’autre information que de signaler une présence, qui ne disent rien d’autre que « Je suis disposé à te parler ».

La communication internet regorge de ces éléments phatiques : la boule verte qui dit que je suis disponible pour tchater, le « like », le « poke », mais aussi le simple fait de retweeter ou d’ajouter à ses favoris.

Cette communcation phatique devient de plus en plus omniprésente, et le malentendu peut s’installer. En effet, elle renvoie constamment à l’autre la responsabilité d’interpréter ce que je suis en train de dire. Que suis-je en train de dire quand je « like » un contenu sur Facebook ? Si je retweetee un message ambigu sur Twitter, suis-je en train d’y adhérer ? Parfois, non. Le fait de retweeter un message peut complètement inverser son sens. Et ces glissements de sens peuvent entraîner des réactions fortes.

Donc Internet est moins le lieu d’une communication agressive, que celui d’une communication ambiguë, complexe, créatrice de malentendus, et pour laquelle nous n’avons pas encore tous les codes.

[...]

En même temps, prenons un peu de recul. Dans n’importe quel choix et n’importe quelle prise de décision politique, il y a un niveau d’aveuglement nécessaire, un moment de folie où on accepte de faire quelque chose tout en sachant que ce n’est pas la solution parfaite. Dans tout mouvement politique, il y a des moments où on dit « arrêtons de discuter, faisons, et on verra après ».

Nous avons eu ce moment d’aveuglement nécessaire, ce moment où nous avons cru aveuglément en Internet, et les conséquences de ce moment ne sont pas négligeables. Car si le but, consistant par exemple à établir les conditions d’un débat vraiment démocratique, n’est pas encore atteint, nous avons tout de même fait le premier pas consistant à considérer ce but comme souhaitable.

[...]

Ce qui m’insupporte au plus haut degré, c’est l’alarmisme et la panique morale qui s’installent d’un côté ou de l’autre. Chez ceux qui voudraient conserver les vieux équilibres et qui disent qu’Internet, c’est le triomphe de l’anarchie (si seulement c’était vrai...). Et chez ceux qui y voient seulement le triomphe de la surveillance. Ces types d’alarmisme et de clivage manichéen desservent tout progrès politique. »

Via http://seenthis.net/messages/326690

« The Amount of Nonsense Packed Into the term "BIG DATA" Doubles Approximately Every Two Years »

:')

ip r s proto zebra : voir les routes ajoutées dans la FIB par le démon zebra de quagga
ip r s proto bird : même chose mais avec BIRD
ip -6 r s proto ra : même chose mais avec les messages ICMPv6 router advertisement
ip (-6) r s proto kernel : même chose mais avec l'autoconf (link locale v6, route de l'if en v4/v6, ...)

Quand on ajoute beaucoup de routes à partir d'un script par exemple, pourquoi ne pas créer notre numéro de protocole ? La visualisation et la suppression des routes ajoutées en cas d'erreur ou à la fin du process en devient super simple : ip r (show | flush) proto <notre_proto>. Après tout, on peut bien nommer des tables de routage alternatives (c'est dans /etc/iproute2/rt_tables que ça se passe, cf http://shaarli.guiguishow.info/?xT-HMA pour un cas d'usage) alors pourquoi pas un protocole ?

Hé bah si, c'est dans /etc/iproute2/rt_protos que ça se passe !

Exemple :
echo "245 exemple" >> /etc//iproute2/rt_protos
ip r a a 192.0.2.0/24 dev <dev> proto exemple
ip r f proto exemple

OWI, comment injecter des préfixes dans un routeur BGP à partir d'une RIB au format MRT. Pratique quand on veut utiliser une full view dans un lab mais que l'on n'a pas un routeur de la DFZ sous la main.

Seul inconvénient : le parse pour injection avec bgpsimple est long : il faut compter ~20 mns pour un dump de 7,8 millions de lignes et jusqu'à ~1h pour un dump de 13 millions de lignes, en fonction de la vitesse de votre CPU. Bien que la la full view v4 tourne actuellement autour de 513000 routes, il ne faut pas oublier que la taille du dump dépend de la connectivité du routeur qui l'a produit : plusieurs chemins = plusieurs entrées dans la RIB, certains opérateurs désagrègent les préfixes, ...


Quelques améliorations/màj du tuto :

libbgpdump/bgpdump
    * Dernière version de libbgpdump : http://www.ris.ripe.net/source/bgpdump/libbgpdump-1.4.99.13.tgz


    * apt-get install libbz2-dev zlib1g-dev

      Si vous ne le faites pas avec le ./configure, alors vous aurez l'erreur suivante lors de la compilation :
          libbgpdump.a(cfile_tools.o): In function `cfr_open':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:91: undefined reference to `gzdopen'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:144: undefined reference to `BZ2_bzReadOpen'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:147: undefined reference to `BZ2_bzReadClose'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:162: undefined reference to `gzopen64'
          libbgpdump.a(cfile_tools.o): In function `cfr_close':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:206: undefined reference to `gzclose'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:199: undefined reference to `BZ2_bzReadClose'
          libbgpdump.a(cfile_tools.o): In function `cfr_read':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:307: undefined reference to `gzread'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:310: undefined reference to `gzeof'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:267: undefined reference to `BZ2_bzRead'
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:291: undefined reference to `BZ2_bzReadClose'
          libbgpdump.a(cfile_tools.o): In function `cfr_getline':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:394: undefined reference to `gzgets'
          libbgpdump.a(cfile_tools.o): In function `cfr_strerror':
          /home/guigui/libbgpdump-1.4.99.13/cfile_tools.c:473: undefined reference to `gzerror'
          collect2: error: ld returned 1 exit status

     Vous pourrez toujours relancer la config' de la compil' ou ajouter « -lz -lbz2 » à la variable CFLAGS.


    * « ./configure --disable-ipv6 » -> non, en 2015 on compile avec le support IPv6 !


    * Lors du make install, vous aurez l'erreur suivante :
     
      make: *** Pas de règle pour fabriquer la cible « testbgpdump », nécessaire pour « install ». Arrêt.

      Il suffit de : sed -i s/testbgpdump// Makefile puis de relancer make install


    * bgpdump permet d'écrire directement dans un fichier, pourquoi écrire sur stdout puis rediriger ?
     
      zcat bview.20090820.2359.gz | bgpdump -m - > rib.ris.20090820.2359
        s'écrit
      zcat bview.20090820.2359.gz | bgpdump -m -O rib.ris.20090820.2359 -


    * Dans le même ordre d'idée, bgpdump accepte désormais les fichiers compressés (gzip, bzip2) en entrée

      zcat bview.20090820.2359.gz | bgpdump -m - > rib.ris.20090820.2359
        s'écrit
      bgpdump -m -O rib.ris.20090820.2359 bview.20090820.2359.gz


    * Il n'y a pas que le RIPE qui propose des RIB au format MRT. Le projet Route Views (http://www.routeviews.org/) propose aussi cela.

      Exemple :
        wget ftp://archive.routeviews.org/route-views.linx/bgpdata/2014.12/RIBS/rib.20141230.1400.bz2
        bunzip2 rib.20141230.1400.bz2 ; bgpdump -m -O rib.rw.20141230.1400 rib.20141230.1400 ou, directement : bgpdump -m -O rib.rw.20141230.1400 rib.20141230.1400.bz2




bgpsimple
    * Dernière version de bgpsimple : wget http://bgpsimple.googlecode.com/svn/trunk/bgp_simple.pl

    * chmod +x bgp_simple.pl

    * Par défaut, il écrit les updates qu'il effectue sur stdout même si on ne lui demande pas d'être verbeux ! Ce comportement tue les performances (~6000 lignes parsées par minute avec affichage, ~13000 sans affichage !). Pour virer l'affichage, il faut mettre en commentaire les lignes 640 à 649 :
=pod
                sub_debug ("u", "Send Update: ")                        if (!$dry);
                sub_debug ("u", "Generated Update (not sent): ")        if ($dry);
                sub_debug ("u", "prfx [$prefix] aspath [$aspath] ");
                sub_debug ("u", "locprf [$local_pref] ")                if ($peer_type eq "iBGP");
                sub_debug ("u", "med [$med] ")                          if ($med);
                sub_debug ("u", "comm [@communities] ")                 if (@communities);
                sub_debug ("u", "orig [$nlri[7]] ");
                sub_debug ("u", "agg [@agg] ")                          if (@agg);
                sub_debug ("u", "atom [$atomic_agg] ")                  if ($atomic_agg);
                sub_debug ("u", "nxthp [$nexthop]\n");
=cut


    * Si vous utilisez des routeurs logiciels, il vous faudra deux machines (ou jouer avec les netns / VM) car le routeur d'en face ne se laissera pas berner par une IP locale (une IP présente sur l'une des interfaces de la machine (lo, eth0, ...) + l'option « -nolisten » de bgpsimple. BIRD le signale très clairement : « bird: bgp1: Invalid remote address 198.18.0.1) »


    * À l'usage, j'ai remarqué un problème : dès la fin de l'émission des updates, bgpdump se plaint que le hold timer a expiré. Pourtant le routeur d'en face (pour vérifier avec Quagga : sh ip bgp neighbor) lui a bien envoyé des keepalive régulièrement. Ce comportement est identique que bgpdump soit client ou serveur (que ce soit lui qui initie la connexion ou pas). La solution est que le holdtime soit supérieur à la durée que prendra le parse du fichier. Exemple : s'il faut 20 minutes pour injecter le fichier, un holdtime de 15 minutes ne passe pas. C'est plus ou moins approximatif : s'il faut 22 minutes pour injecter, un holdtime de 20 minutes semble passer.

     Mon avis est que bgpsimple et surtout la lib utilisée, Net::BGP::, ne sont pas multi-threadés. Ils ne font donc qu'envoyer les updates sans prendre en compte les keepalive (la fonction de callback n'est pas exécutée) durant cet intervalle. Donc, à la fin de l'émission des updates, le holdtime a expiré, en effet.

     La seule solution que je vois est de configurer un intervalle de keepalive et surtout un holdtime supérieur à la durée d'injection du fichier. Cela se fait avec les arguments « -keepalive <secs> » et « -holdtime <secs> ». Il faut que ça coïncide avec les intervalles définis dans le routeur à l'autre bout. Sous Quagga « timers bgp <keepalive en secs> <holdtime en secs> ». Pour BIRD : « keepalive time <secs>; » et « hold time <secs>; »




Comment produire vos propres dumps au format MRT avec des routeurs logiciels ?
De tous les messages BGP (OPEN, UPDATE, NOTIFICATION, ...) :
    - Quagga : « dump bgp all path interval » dans bgpd.conf

    - BIRD : « mrtdump "/path/to/filename";» en global puis soit « mrtdump protocols { messages }; » en global pour appliquer à toutes les instances BGP, soit « mrtdump { messages } ; » dans les instances désirées.


De tous les messages UPDATE :
    - Quagga : « dump bgp updates path interval »

    - BIRD : pas d'équivalent


De la RIB BGP :
    - Quagga : « dump bgp routes-mrt path interval ». Exemple :  dump bgp routes-mrt /var/run/bgpdata/%Y-%m/rib.%F.%H%M 15m , le dossier doit exister (même dernier niveau, ici /%Y-%m) et doit être accessible en écriture par l'utilisateur quagga (chown ...)

    - BIRD : pas d'équivalent. mrtdump ne permet pas cela, la commande « dump resources|sockets|interfaces|neighbors|attributes|routes|protocols » de birdc ne produit pas une sortie au format MRT et il s'agit d'un dump de la FIB (on a perdu les attributs BGP autre que préfixe et next-hop, cf code : « FIB_WALK() » dans rt_dump() ). Exemple de sortie :
1.22.89.0      /24 KF=80 PF=00 pref=100 lm=17 p=bgp1 uc=1 RTS_BGP univ UNREACH h=52f2 <-198.18.0.1 EA: [SbC] 01:01.40=i:00000000 01:02.40=P[18]:020400001b6a00000da30000d8720000b1d8 01:03.40=I[4]:3f01000c 01:05.40=i:00000000 01:08.c0=S[8]:88136a1b70916a1b

     Si vous aussi vous cherchez la « debugging output. » dont parle le manuel à propos de la commande dump, il ne s'agit pas des sorties configurées dans le fichier de conf' avec les directives « log » et « debug », non. Si l'on lit le code source (utilisation de la fonction debug() définie dans sysdep/unix/log.c qui écrit dans un handler ouvert par log_init_debug(char *f) toujours dans le même fichier qui elle, est appelée par main() dans sysdep/unix/main.c en fonction des arguments passés à BIRD), il faut lancer BIRD avec les arguments : « -D /path/to/filename » ou « -d (stderr implicite) ». En effet, ça fonctionne mais alors BIRD ne devient plus un démon... Pas top.

C'est tellement vrai... Poodle (cf http://shaarli.guiguishow.info/?GPqmpA), le talk de Jacob et Laura au 31C3 sur NSA versus VPN/Tor/SSH/HTTPS, ... C'est à chaque fois pareil. Prudence et patience, les gens...

Via https://twitter.com/bortzmeyer/status/549870757539356672

J'ai eu à installer un Debian Wheezy sur un ordinateur équipé d'une carte mère Asus P5K Prenium. Cette carte mère n'a pas de port floppy. Donc aucune option dans le BIOS pour désactiver un truc qui n'existe pas. ;)

J'utilise une iso netinstall.

Durant l'installation, Debian Installer voit un lecteur de disquettes et forcément, n'arrive pas à interagir avec lui : « Buffer I/O error on device fd0, logical block 0 ». Donc l'installation bloque à 40 % de l'étape de détection des disques...

Dans le BIOS, on voit un paramètre « emulation type » pour les périphériques de stockage USB. Il y a une option « floppy ». Mais par défaut, la valeur est « auto ». La passer cette valeur de « auto » à « hard drive » ne change rien.

Ajouter « rdblacklist=floppy » à la cmdline du noyau depuis le menu de boot ne change rien.

Solution qui a marché pour moi : ouvrir une console dès le début de l'installation, avant d'arriver à la phase de détection des disques durs avec ctrl+alt+F2. Utiliser les commandes :
    - rmmod floppy
    - echo "blacklist floppy" > /etc/modprobe.d/blacklist.conf

Une autre solution qui pourrait fonctionner : https://www.debian.org/releases/stable/i386/ch05s03.html.en#module-blacklist . Via b4n.

L'installation se déroule sans problèmes. Une fois le système installé, refaire préventivement echo "blacklist floppy" > /etc/modprobe.d/blacklist.conf .

Une erreur « fd0 read error » persiste avant l'apparition du menu de GRUB2. On est donc bien avant initrd/linux. Cette erreur n'est pas bloquante mais elle ralentit le processus de boot d'environ 5-7 secondes. Je n'ai pas trouvé de solution et, vu le faible gain possible, j'ai renoncé. Ce problème (en tout cas le lag qu'il produit) semble avoir été corrigé dans la version 2.00-1 de GRUB2, cf : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632408 . Debian Jessie ne devrait donc plus avoir ce problème. Wait&see. Merci à b4n pour l'info.