GuiGui's Show

J'avais déjà testé les enregistrements SSHFP afin de valider, via le DNS, les clés publiques de mes serveurs persos (voir http://shaarli.guiguishow.info/?X1OYWg). Maintenant que mes desktops sont sous Jessie, dans laquelle la version packagée d'openssh-client supporte les condensats sha256 dans le RDATA des enregistrements SSHFP ainsi que le type ecdsa, entre autres choses, c'est l’occasion de déployer pour de vrai.

Il vous faut :
    * Des zones DNS signées avec DNSSEC sinon l'intérêt de SSHFP est nul.
       Si vos zones ne sont pas signées (cas d'un hébergeur, comme OVH pour les zones comme kimsufi.com, par exemple), laissez tomber. Utiliser une zone signée + CNAME ne fonctionnera pas : CNAME ne peut pas se cumuler avec un autre type d'enregistrement. La seule piste envisageable, c'est de dupliquer, dans ma zone signée les enregistrements de type A et AAAA et d'y ajouter les enregistrements SSHFP mais c'est vraiment crade : vous dupliquez dans une zone des informations d'une autre zone d'où un coût en maintenance supérieur et un risque d'erreur accru. ;


    * Si vous utilisez ssh-keygen pour générer les enregistrements SSHFP, il vous faut la partie publique des clés de votre serveur au format openssh. Si vous avez du dropbear (exemple : OpenWRT), il faudra d'abord la convertir.
        * sudo apt-get install dropbear
        * /usr/lib/dropbear/dropbearconvert dropbear openssh <cle_dropbear> <cle_dropbear>.ssh
        * La partie publique n'est pas stockée sur mon périphérique OpenWRT... générons-la à partir de la partie privée que nous venons de convertir (https://askubuntu.com/questions/53553/how-do-i-retrieve-the-public-key-from-a-ssh-private-key) : ssh-keygen -y -f <cle_dropbear>.ssh > <cle_dropbear>.ssh.pub

        * ssh-keygen -r <hostname> -f <cle_dropbear>.ssh.pub . Deux enregistrements sont produits. Le plus court utilise sha1 pour produire le condensat, le plus long utilise sha256. De nos jours, avec sha1 qui commence à montrer des signes de faiblesse, il faut utilise sha256.


    * Publier les enregistrements SSHFP.


    * Un openssh-client compilé avec la lib ldns lui permet de faire les vérifications DNSSEC et donc de s'assurer que l'information n'a pas été altérée. Ce n'est pas le cas avec Debian : openssh-client n'est pas compilé avec libldns (ldd $(whereis -b ssh) pour vérifier). Donc, il faut impérativement un récursif-cache validant sur votre machine (voir dnssec-trigger, http://shaarli.guiguishow.info/?uEnUXw) ou, à défaut sur le réseau local qui doit alors être de confiance (VPN, réseau domestique...) et pas de WiFi (oui, même WPA1|2 car la clé est partagée entre les utilisateurs du réseau. Et même avec ça, il reste le problème des switchs réseaux mais comme d'hab, ça dépend de qui vous voulez vous protéger).
        Il faut bien comprendre que, sans la lib ldns, la validation des enregistrements DNSSEC est effectué par le récursif-cache validant que vous utilisez. Celui-ci signale qu'il a réalisé le travail de vérification en plaçant le flag "AD" (Authenticated Data) dans le header du message DNS... qui n'est pas signé : un MITM (ou un mensonge du récursif-cache utilisé) reste donc possible.

    * Activer la vérification des SSHFP en ajoutant ceci à votre .ssh/config :
        « Host *
              VerifyHostKeyDNS=yes »

      Vous pouvez aussi restreindre seulement aux machines dont vous savez que le déploiement est effectif. Ça ne change rien pour les machines qui n'ont pas de SSHFP associé à leur clé publique, known_hosts sera alors utilisé mais vous ne ferez pas de requêtes DNS inutiles pour ces machines-là.

      À partir de ce moment-là, SSH n'utilise presque plus .ssh/known_hosts mais uniquement le DNS, SAUF si le client utilise un récursif non validant ou que le SSHFP est outdated, auquel cas le client SSH fallback sur le fichier known_hosts. À la mise en service d'une nouvelle machine (virtuelle ou non), il faudra publier son SSHFP avant de faire un SSH sinon l'absence de réponse sera mise en cache et une validation manuelle sera nécessaire (comme sans VerifyHostKeyDNS quoi). Même chose lors d'un changement de la clé du serveur : il faudra pré-publier et attendre l'expiration du TTL du vieil enregistrement SSHFP avant d'être sûr que le nouveau arrive dans le cache... Les clients n'ont plus besoin de mettre à jour leur known_hosts.


    * Vérifier : ssh -vvv serveur :
        * Si vous utilisez un récursif-cache qui ne valide pas (ÉDIT DU 08/07/2023 : sur une version plus récente de la libc, il faut explicitement activer la validation DNSSEC dans /etc/resolv.conf, cf. http://shaarli.guiguishow.info/?LAZf0g. FIN DE L'ÉDIT.) :
          « debug3: verify_host_key_dns    
            debug1: found 1 insecure fingerprints in DNS
            debug1: matching host key fingerprint found in DNS »
          Et SSH vous demandera une confirmation manuelle de la clé du serveur.

        * Avec un récursif-cache validant :
          « debug3: verify_host_key_dns
            debug1: found 1 secure fingerprints in DNS
            debug1: matching host key fingerprint found in DNS »
          Et vous êtes connectés automagiquement à votre serveur.

Via http://www.bortzmeyer.org/4255.html

Mon ordinateur portable Clevo P170HMx m'a lâché en mai/juin dernier : écran quasiment 100% bleu dès l'allumage et plus d'affichage du tout dès que le système prend la main (oui, même un winwin 7...). Il faut savoir que je n'utilisais plus autant cet ordinateur qu'avant (1 ou 2 fois tous les 15 jours) mais qu'il restait quand même branché au secteur et qu'il était posé sur la même table que le reste de mon matos... Donc on est OK pour la qualité de l'alim électrique, humidité & co.

Heureusement, il a été pris en charge par la partie "risques électriques" de mon assurance habitation et il a été remplacé à neuf par un Asus G751JL (non, je n'ai pas eu le choix).

C'est la goutte qui fait déborder le vase vu les autres emmerdes que j'ai eu avec ce Clevo (http://shaarli.guiguishow.info/?sxgfPg). Du coup, j'ai fait un point sur tous les autres ordinateurs portables que j'ai eu afin de voir si le Clevo était une exception par sa médiocrité ou bien s'il était dans une sorte de norme...


Compaq CQ61-407SF :
    * + Finition : j'aimais beaucoup la sensation de frappe sur ce clavier ;
    * + Une puce WiFi Atheros AR9285 compatible avec l'injection Aireplay <3 C'était l'bon temps ;
    * + Fonctionnait très bien sous Debian GNU/Linux Squeeze ;
    * + Installation facile d'un système libre : secure boot et co n'existaient pas encore ;
    * - Composants durs à changer donc prix délirants. Je me souviens de la nappe de la dalle LCD qui était dans un format vaseux, nécessitant d'acheter la dalle kiVaBien à prix d'or (146€ TTC, soit 37% du prix initial d'achat !). Je n'ai pas eu de problèmes, je m'étais renseigné "pour voir" et j'avais choisi l'écran car je sais que c'est sur ce composant qu'on voit les trucs hallucinants sur un ordi portable.


Clevo P170HMx :
    * + Des 4 machines que je compare ici, il est celui qui se démonte le plus facilement, c'est une évidence ;
    * + PC portable personnalisable ;
    * - Cette personnalisation a un coût plutôt exorbitant quand on y regarde bien et le choix est plutôt réduit : choix entre deux modèles de processeur, 4/8/16G de RAM,... Mouais... Dell aussi est personnalisable dans ce cas-là ;
    * + Installation facile d'un système libre : secure boot et co n'existaient pas encore. À part le WiFi, tous les drivers étaient libres ;
    * - Mais même avec ça, la puce WiFi Realtek 8188CE était vraiment merdique et le WiFi quasi inutilisable ;
    * - Comment détecter les composants vaseux ? L'acheteur est-il mieux informé qu'avec un ordinateur acheté dans le commerce ? Je n'en suis pas sûr. Genre j'ai choisi un mauvais SSD qui castrait littéralement les perfs que même un disque dur WD 7200rpm de récup' pénalisait moins la machine. Je me souviens que le site web d'Anyware (revendeur FR Clevo) n'indiquait pas la marque/modèle, juste "SSD de 128G". Même chose pour la puce WiFi sauf que je n'avais pas le choix ;
    * - Aucune finition. Aucun plaisir à taper sur ce clavier d'autant que l'entourage plastique/métal vous gèle les poignets en parallèle... ;
    * - Je m'attendais à un BIOS avec beaucoup d'options compte tenu du côté personnalisable mais non... Plus qu'un laptop acheté en grande surface mais pas novateur non plus. J'ai été très déçu sur ce point ;
    * - SAV d'Anyware (revendeur FR) plutôt décevant surtout dans le relationnel ;
    * - J'ai raconté ici (http://shaarli.guiguishow.info/?sxgfPg) que la carte mère de rechange n'était pas arrivée au bout de 7 semaines entre les mains du SAV d'Anyware. Soit environ 2 ans après la mise sur le marché, Clevo semble ne plus pouvoir assurer des livraisons de pièces détachées dans un délai convenable... On est donc au niveau de tous les autres fabricants/assembleurs de matos électro-ménager. Quel intérêt de choisir Clevo, alors ?


Dell Latitude E6540 :
    * + Finition. J'aime beaucoup la frappe au clavier et l'espèce de caoutchouc sous les poignets. Il y a eu du travail sur le design, sans que ça soit démesuré, et ça se voit ;
    * + Batterie 9000mAh qui tient 4-5h ;
    * + Un EFI, oui, mais le plus complet que j'ai jamais vu... Des options utiles à la pelle comme désactiver micro/webcam... Presque chaque composant peut être désactivé et beaucoup de choses sont configurables. Juste GG <3
    * + Un SAV qui poutre vraiment. Le meilleur SAV auquel j'ai eu affaire dans ma vie. De la relation humaine au suivi en passant par la réparation sans te prendre pour un con, juste GG. <3
    * + Une puce WiFi qui juste fonctionne ;
    * + Installation facile d'un système libre : secure boot est présent mais se désactive facilement. À part le WiFi, tous les drivers sont libres ;
    * - Les boutons du touchpad sont plutôt mal fichus et cliquent plutôt mal ;
    * - Ça reste vendu à prix d'or ;
    * Note :  le fameux mouchard Computrace (voir : http://korben.info/computrace-lojack-absolute.html) n'est pas actif par défaut et peut (doit) être désactivé dans l'EFI sans possibilité de réactivation ultérieure ;


Asus G751JL :
    * Note : Je n'ai pas assez de recul pour juger ;
    * - Aucune finition, rien... Même problème que Clevo. C'est juste ignoble ;
    * - Des trucs WTF :
        * La batterie n'est pas amovible directement (faut dévisser, sérieux !) ;
        * Le touchpad ne peut pas être désactivé matériellement, ce n'est qu'un raccourci pour qu'un logiciel proprio d'Asus (ASUS Smart Gestures), le désactive. BTW, c'est quoi le délire d'avoir mis un touchpad aussi démesuré ?!
        * La connectique est mise n'importe où... J'apprécie (ironie) tout particulièrement l'ethernet et les 2 ports USB au niveau de la souris... Très futé !
    * - Une puce WiFi vaseuse (Intel Wireless 6725) ;
    * - L'installation d'un système libre est un enfer... Dénominations absconses dans le BIOS pour virer secure boot & co... En même temps, sur cette gamme, Asus ne s'attend pas à voir du GNU/Linux... La carte réseau ethernet Realtek et la carte WiFi nécessitent des drivers proprios. Le son ne fonctionne pas sauf à brancher un casque sur line-out. Impossible de revenir d'un suspend-to-ram. Je n'ai pas cherché comment désactiver le touchpad... Voir http://shaarli.guiguishow.info/?Nn1Pyg


J'aurais bien voulu tester du Lenovo Thinkpad car j'en ai toujours entendu et vu le plus grand bien. Mais depuis Superfish (adware + MITM TLS, voir http://shaarli.guiguishow.info/?BxfR0Q) et la backdoor Lenovo Service Engine (voir http://shaarli.guiguishow.info/?X9TOQQ), je n'ai plus du tout envie de m'approcher de Lenovo...

Notons que je ne peux pas comparer avec mes desktops puisque j'ai vu passer 4 desktops dont 2 achetés tout prêt dans le commerce et 2 montés par mes soins et que ça c'est toujours bien passé, même avec secure boot pour le dernier PC acheté.


Ce que je retiens :
    * Plus jamais de Clevo. Au-delà des pannes (quelques exemplaires défectueux, ça peut arriver, sans compter que tous les assembleurs ont connus une période catastrophe), j'trouve qu'on ne gagne pas grand-chose : la personnalisation est plutôt limitée, on n'a pas vraiment plus d'informations sur les composants (voir les exemples que j'ai donnés), la pérennité de l'approvisionnement en composants de rechange n'est pas assurée comme partout ailleurs, un SAV décevant, tout ça pour un prix plus élevé.

    * Je pense aussi que les gros assembleurs traditionnels (HP, Lenovo, Asus,...) ont un rôle à jouer dans la chaîne : ils peuvent tester plusieurs combinaisons de composants et détecter les incompatibilités sur des chaînes de test. Du coup, ils arrivent sûrement à détecter les tendances des constructeurs de composants qui traversent une phase difficile et qu'il faut donc s'interdire d'utiliser temporairement. Si la conception d'une machine est fumeuse, il y a aura de forts retours SAV donc des actionnaires fortement mécontents alors que si je me plante dans le choix des composants sur le site web d'Anyware, ça emmerde que moi-même. Alors oui, ces assembleurs sont aussi plus sensibles aux magouilles du genre "je te fais telle ristourne si on signe un gros contrat de collaboration sur une longue durée" ou "si on arrête de bosser ensemble , c'est pour toujours", c'est bien comme ça que Microsoft s'est imposé. No free lunch.

    * Des ordinateurs qui fonctionnent comme un charme sous GNU/Linux, il y en a aussi dans les grandes surfaces en provenance de gros assembleurs. Par contre, un des avantages indéniables de Dell et Clevo, c'est que je n'ai pas payé la patente winwin et j'ai montré mon désintérêt sans avoir à faire des pieds et des mains pour me faire rembourser après coup.

    * Pour l'anecdote : le Compaq était le seul 15 pouces premier prix dans les grandes surfaces proches de chez moi à l'époque. Je l'ai acheté parce que mes seuls critères étaient 15 pouces + prix le plus bas possible. J'ai acheté le Dell car il répondait à mes besoins : 15 pouces, autonomie, SSD, perfs CPU, pas besoin de perfs GPU. Comme d'habitude, c'est ça qui est important : définir ses critères (aka ce que l'on veut) et ensuite trouver la machine adaptée, peu importe le lieu d'achat ou l'assembleur. Pour le Clevo, j'ai fait une fixation sur personnalisable, "petit" revendeur, matos facilement démontable, pas de licence winwin mais est-ce que c'était important et pertinent, en regardant après coup ? Bien sûr que non.

    * Du Compaq (ou HP Compaq de nos jours mais ma remarque reste valable) que ça soit en desktop ou en laptop, ça juste marche sous GNU/Linux.

Si tout ça peut éclairer votre prochain achat de matos... Le petit revendeur qui livre des configs custom n'est pas plus votre ami que la grande surface qui livre des configs standardisées de gros assembleurs.

J'ai brièvement parlé de VeraCrypt, fork maintenu de TrueCrypt, dans un shaarli (http://shaarli.guiguishow.info/?pZI4Og) et j'ai eu envie de voir ce que ça donne afin de voir si c'est recommandable.

Ce que je retiens de VeraCrypt :
    * L'interface reste la même donc toute la documentation TrueCrypt reste valable ;

    * Ce fork est maintenu, TrueCrypt ne l'est plus. Or, les mises à jour de sécurité sont capitales. Deux failles ont déjà été remontées en septembre 2015 (sans compter les failles mineures dans TrueCrypt remontées par l'action du Open Crypto Audit Project) ;

    * Paradoxalement, TrueCrypt a été audité, des personnes ont même vérifié que les sources distribuées produisent bien le binaire qui est distribué (compilation reproductible), ce qui n'est pas le cas de VeraCrypt. VeraCypt a peut-être des backdoors ? On ne sait pas : moins d'yeux pour se pencher dessus ;

    *  Un nouvel algo de chiffrement (SHA256), un algo déprécié sauf si chiffrement de la partition système (RIPEMD160). SHA-512 devient le nouvel algo de dérivation passphrase -> clé de chiffrement ;

    * Si vous chiffrez votre partition système, VeraCrypt vérifie, à chaque boot, l'intégrité du bootloader et vous en avertit. Ceci dans l'optique de prévenir d'une possible attaque « Evil Maid » (https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html) qui serait en cours. Le mal est fait mais vous êtes prévenus. Bien évidemment, dans un setup avec luks à côté (http://www.guiguishow.info/2011/08/31/installer-windowstruecrypt-fde-et-gnu-linuxdm-crypt-sur-le-meme-disque-dur/), ça va hurler sans arrêt puisque le bootloader est GRUB ;

    * Afin de rendre le bruteforce plus compliqué, les devs de VeraCrypt ont augmenté le nombre d'itérations lors de la dérivation passphrase -> clé de chiffrement donc le temps d'ouverture des volumes chiffrés a clairement augmenté... Sur un ordinateur récent, ça prend quasiment une minute pour ouvrir la partition système chiffrée. Je ne suis pas convaincu par la manip' : avec une mauvaise passphrase (trop courte, pas assez complexe), les itérations supplémentaires feront certes patienter l'attaquant mais avec une vraie passphrase, les itérations supplémentaires feront passer le temps nécessaire à la réussite d'un bruteforce de 1 million d'années à 10 millions (exemple pifométrique)... Ouais, ok, ça dépasse laaaargement mon modèle de menace. De plus, d'ici là, AES sera probablement tombé ou mes genoux en miettes (https://xkcd.com/538/), mais c't'un détails, sans doute. Apprendre aux utilisateurs à choisir une vraie passphrase me semble plus prometteur. La lenteur à l'ouverture me fait craindre un désintérêt des utilisateurs lambdas.

À part le troisième point, VeraCrypt me semble recommandable : on garde TrueCrypt et on améliorer et on le maintient.

Nous sommes beaucoup de beaux parleurs à vouloir une presse qui fasse son taff de quatrième pouvoir mais nous sommes peu à financer les journaux qui sortent du lot. L'argument clé, c'est le prix...

Depuis juillet 2015, je me paye plusieurs journaux :
    * Canard enchaîné : 73,50€/an (hebdo + les dossiers)
    * Mediapart : 90€/an
    * NextInpact : 90€/an (l'abonnement commence à 35€/an mais je voulais être premium avec toutes les options car je pense que ça l'vaut bien)
    * Arrêt sur Images : 45€/an
TOTAL : environ 300€/an soit environ 25€/mois.

Alors oui, il y a d'autres médias qui m'intéressent qui sont en besoin de financement. Charlie... Sauf que mes tentatives de paiement ont échouées. Reflets.info.. Sauf que leur teasing permanent et leur suffisance ("regardez, ça fait des années qu'on le dit") masquent le très bon fond de cette initiative.

25€/mois... Pour 4 journaux. Pour des dossiers, des analyses poussées (fibre optique, projets de loi liberticides, manipulations mentales,...), des infos fraîches (nan parce que les dépêches AFP de faits divers en boucle, oui, en effet, ça n'a aucun intérêt, ...), une presse différente/unique (regardez les unes versus les unes des autres médias, ça parle tout seul) et soutenir une presse indépendante...

25€/mois... Ça me semble tellement insignifiant que je regrette de ne pas avoir payé de journaux plus tôt, même quand j'étais encore étudiant. J'ai bêtement suivi la "rumeur" qui dit que la presse c'est troooop cher et inaccessible aux étudiants / bas salaires... J'espère que ce shaarli vous permettra de vous faire une autre idée du coût d'une presse sérieuse, différente et indépendante.


Ce shaarli tombe alors que Mediapart et Arrêt sur Images ont lancé des campagnes de don. C'est un hasard : j'ai eu envie de parler de financement de la presse indépendante en citant mon exemple pour montrer que c'est possible et qu'on s'imagine des montagnes alors qu'il n'en est rien.

Pour le coup, je suis plutôt opposé aux campagnes de dons sus-citées : ces deux journaux ont appliqués un taux de TVA réduit jugeant la discrimination papier/numérique glop (et je soutiens ce point : Internet n'est qu'un support/moyen de transport donc rien de justifie cette discrimination sauf le maintien de la perfusion des gros de la presse écrite) et se sont fait redressés par le fisc avant que la loi ne fixe le taux à 2,1% pour toute la presse, numérique ou non. C'était des actes en connaissance de cause, des actes pour faire bouger les choses, de la désobéissance civile. Les premiers recours ont été perdus, les suivants ne sont pas suspensifs donc c'est perdu pour l'instant et il faut sortir la monnaie. Venir geindre et lancer un appel au don après coup, juste non quoi sinon c'est trop facile et dans ce cas, à titre individuel, je me fais financer des procès/pénalités contre des choses que j'estime mauvaises/injustes. La désobéissance ne justifie pas tout. Les lecteurs/rices (de la première heure donc) auraient dû être consultés au préalable sur le taux à appliquer & les risques. Préparer une gagnotte plus importante, quitte à renoncer à d'autres améliorations. Bref, d'autres méthodes étaient possibles.

Hex to ASCII : xxd -r -p

\o/

Ok donc dans Debian Stable, on peut virer le fake ssh-agent de MATE facilement (Système -> Préférences -> Applications au démarrage) mais plus difficilement le gpg-agent... Pour ce faire : « gsettings set org.mate.session gnome-compat-startup "['smproxy']" ». Oui, on fait bien sauter tout gnome-keyring... Puis ajouter « use-agent » dans votre gpg.conf. À partir de votre prochain login, /etc/X11/Xsession.d/90gpg-agent s'occupera de spawn l'authentique gpg-agent.

Les autres méthodes (virer gpg-agent dans Système -> Préférences -> Applications au démarrage, dpkg-divert sur /etc/xdg/autostart/gnome-keyring-gpg.desktop, déplacer tous les fichiers /etc/xdg/autostart/gnome-keyring-*,...) ne fonctionnent pas.

Pourquoi virer le gpg-agent gnome-made ?
    * Chacun son boulot. Ce n'est pas à gnome de s'occuper de gpg/ssh ! ;

    * Le fake gpg-agent n'a pas toutes les fonctionnalités (gestion des cartes à puce, par exemple) ;

    * La personnalisation du délai avant oubli de la passphrase de la clé GPG par le fake gnome-agent se fait avec dconf (voir : https://askubuntu.com/questions/340809/how-can-i-adjust-the-default-passphrase-caching-duration-for-gpg-pgp-ssh-keys). Ce n'est pas intuitif. Enigmail permet de changer ce paramètre facilement depuis ses paramètres quand le vrai gpg-agent est utilisé.

Du coup, j'ai revu ma config en ajoutant :

  * media.eme.enabled -> false. «  JavaScript API for playing DRMed video content in HTML » (https://wiki.mozilla.org/Media/EME)

  * loop.enabled -> false. « Firefox Hello is the new online chat feature being offered by Mozilla Firefox web browser. » (http://www.trishtech.com/2015/01/disable-firefox-hello/ et https://wiki.mozilla.org/Loop/Load_Handling)

  * geo.enabled -> false (« Share Location Data with sites (about:config geo.enabled preference) »)

  * browser.safebrowsing.downloads.enabled -> false. « Non, Google ne connaîtra pas toutes les URL des sites web que je visite en échange d'une prétendue protection. »


J'en profite pour ressortir ce billet complet d'Alda que j'avais mis de côté : http://aldarone.fr/que-fait-firefox-sur-le-reseau-quand-on-le-demarre-et-faut-il-y-remedier/ . Je garde :

« geo.mozilla.org et location.services.mozilla.com correspondent de manière assez évidente à un service de géolocalisation. Mozilla connait donc l’emplacement approximatif de tel navigateur. Ces requêtes disparaissent en passant browser.search.geoip.url à false cela a donc à voir avec les fonctionnalités de recherche comme nous le verrons dans le détails des options.

Enfin, geo.wifi.uri aide la géolocalisation de Firefox à se montrer plus précise en utilisant Google Location Services. Firefox envoie donc votre IP, la liste des réseaux Wifi environnants et un identifiant unique régénéré toutes les deux semaines à Google pour obtenir une localisation fiable au niveau de la rue au lieu de n’avoir que GeoIP qui est fiable au niveau de la ville (et encore, parfois on a que le pays). Sans cette option, la précision prend un sacré coup ce qui peut jouer des tours aux personnes qui en ont l’utilité. »

et :  services.sync.prefs.sync.browser.safebrowsing.enabled -> false + services.sync.prefs.sync.browser.safebrowsing.malware.enabled -> false

Pour l'instant, je veux juste machine0.eth0 + machine1.eth0. La somme des autres interfaces ne m'intéresse pas.

Mais, bientôt, nous aurons des VLAN et là, ça m'intéressera d'agréger machine0.eth0.X avec machine1.eth0.X. Donc bonne remarque, merci. :)

dnssec-trigger est packagé dans Debian Jessie avec une unit systemd et tout. Ça juste fonctionne. \o/

Ça fait plusieurs années que l'on pouvait avoir tout son système GNU/Linux dans un LVM sans avoir de partition /boot séparée. Depuis la version 2.00-22 de GRUB, on peut aussi avoir tout son système dans une partition chiffrée. \o/

Ce tuto fonctionne avec Debian Jessie, testé et approuvé.

Debian-Installer ne permet pas encore de se passer de partition /boot séparée dès l'installation : si l'on n'a pas une telle configuration, il affiche un message bloquant « Vous avez choisi de placer le système de fichiers racine sur une partition chiffrée. Cette fonctionnalité impose d'utiliser une partition /boot dédiée sur laquelle le noyau et l'image disque en mémoire seront stockés. Vous devriez [sic ! ] revenir en arrière et configurer une partition /boot. ». Même  problème à ce jour avec Debian unstable (http://ftp.fr.debian.org/debian/dists/unstable/main/installer-amd64/current/images/netboot/mini.iso).

Pour ceux et celles qui se demandent comment c'est possible genre GRUB fait pas loger LVM+LUKS dans moins de 512o (MBR) : non, voir https://fr.wikipedia.org/wiki/GNU_GRUB#Fonctionnement . « Le MBR contient habituellement la partie 1 de GRUB, mais il peut aussi contenir un autre bootloader qui peut chaîner la partie 1 de GRUB depuis un autre secteur de boot, comme le début d'un autre disque ou une partition logique (de type DOS). À cause de la faible taille du MBR, la partie 1 se contente de charger la partie suivante de GRUB (qui elle peut se trouver n'importe où sur les 1024 premiers cylindres du disque). La partie 1 peut directement charger la partie 2 [ NDLR : qui est "/boot" ], ou charger la partie 1.5, qui se trouve dans les 30 kilooctets suivant le MBR. Cette partie 1.5 charge ensuite la partie 2. La partie 1.5 peut contenir des pilotes pour pouvoir accéder à la partie 2. »

Merci à HS-157 de m'avoir montré cette possibilité.