Récemment j'ai du intervenir sur ma tour parce que j'avais plus tellement de place. J'ai du vite acheter un autre disque dur pour y remédier. Ce qui me donne l'occasion de parler de cette belle technologie sur laquelle je m'étais promis de faire un petit tuto un de ces jours. En théorie RAID est l'a...

Récemment j'ai du intervenir sur ma tour parce que j'avais plus tellement de place. J'ai du vite acheter un autre disque dur pour y remédier. Ce qui me donne l'occasion de parler de cette belle technologie sur laquelle je m'étais promis de faire un petit tuto un de ces jours.

En théorie

RAID est l'acronyme de Redundant Array of Independent Disks (Alignement redondant de disques indépendants), et comme son nom l'indique, il va permettre de regrouper plusieurs disques durs et d'y instaurer une politique de stockage pour faire de la redondance, de l’agrégation de taille, enfin ça répond à plein de besoins différents. En fait on ne devrait pas vraiment parler d'un seul RAID, mais bel et bien de la famille des RAIDs, car en effet il y a autant de RAIDs que de besoins différent.

On va présenter les assemblages RAID les plus utilisés. Pour plus de détails, je vous conseille la page Wikipédia qui est très claire et qui contient des schémas très explicites.

Dans la suite, on va beaucoup parler de bandes de stockage : il s'agit d'une quantité de stockage de valeur prédéfinie, qui correspond à une "section" contiguë du disque qui la contient. Dans ce modèle, lors de l'écriture sur le volume, une bande est d’abord remplie avant d'en entamer une suivante. Il s'agit en fait d'abstraire le stockage et de pouvoir mieux comprendre la répartition des données sur les différents disques.

RAID 0

Les bandes sont tout bonnement distribuées sur les disques, toujours dans le même ordre. On remplit donc une bande par disque, puis une fois qu'on a touché à tous les disques, on repart du premier disque et on recommence une couche de bandes. Tous les disques contiennent des données différentes. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera nx.

• Avantages : Ce montage permet d'utiliser le plus grand espace possible de votre assemblage. De plus, en moyenne, les accès disques parallèles seront plus rapide, pour peu que ces accès disques se fassent dans des bandes différentes et sur des disques différents.
• Inconvénients : Il suffit de perdre un seul disque pour corrompre l'intégralité des données. Or, statistiquement, plus on a de disques, plus on a de chances d'en perdre.

RAID 1

Les bandes sont écrites à l’identique sur tous les disques. Tous les disques contiennent exactement les même données. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera x.

• Avantages : C'est le montage qui permet la plus grande sécurité des données faces aux pannes : tant qu'il vous reste un disque fonctionnel, vos données sont intactes et complètes. Les accès disques sont aussi nettement améliorés, avec une vitesse théorique multipliée par le nombre de disques dans le montage.
• Inconvénients : Il est frustrant d'avoir beaucoup de disques durs pour avoir au final l'espace d'un seul disque. Évidemment les données sont très sûres mais quand même, faut pas pousser...

RAID 5

Les bandes sont réparties sur tous les disques sauf un, qui reçoit une bande de parité. La bande de parité est tout simplement une bande dont chaque bit est obtenu en appliquant le OU exclusif (XOR) à l'ensemble des bits correspondants dans les bandes alignées des autres disques. Cette bande de parité est attribuée à chaque disque alternativement au fil des couches de bandes remplies. Donc si un disque vient à tomber en panne, pour chaque couche de bande, si la bande du disque en panne est la bande de parité, alors les données de la couche sont intactes. Si la bande contient de la donnée, alors elle peut être recalculée à partir des autres couches de données et celle de parité. C'est du calcul logique, et c'est la force du XOR. Ainsi, si vous avez n disques durs de capacité exploitable x, la capacité totale du montage sera (n-1)x.

• Avantages : Un bon compromis entre place exploitable et sécurité des données. On se donne le droit de perdre un disque dur dans la bataille. Pour retrouver l'usage des données, il suffit de remplacer le disque défaillant et les données sont reconstruites.
• Inconvénients : Ça dépends des cas, mais un droit à un unique disque dur en panne, ça peu être peu. Pour certain ça peut être insuffisant.

RAID 6

Il s'agit d'une extension du RAID 5 dans laquelle on se permet de pouvoir perdre plus d'un disque. La solution étant d'attribuer plus de bandes de "parité" par couche, une par nombre de pannes maximum permises. Ici, j'utilise les guillemets car il ne s'agit plus vraiment de la parité simple de la logique de base, mais d'un truc chelou reposant sur un principe tout autre dont je ne pas trop vous parler parce que j'en ignore tout. Donc si vous avez n disques durs de capacité exploitable x, et si vous mettez en place k bandes de redondance par couche, la capacité totale du montage sera (n-k)x.

• Avantages : On se sent un peu plus à l’abri des intempéries matérielles, au pris d'un peu de place de stockage.
• Inconvénients : Le principe chelou dont je vous ai parlé, enfin dont je ne vous ai pas parlé pour être honnête, eh bien il est tellement chelou qu'il pète pas mal les performances. Et pour couronner le tout, la plupart des implémentations de ce type d'assemblage est bien moins stable que les autres.

Il est également possible de combiner les RAIDs. Une combinaison fréquente est le RAID 10 (RAID 1 + RAID 0). Par exemple si on a 10 disques, on peu monter 2 RAID 1 de 5 disques chacun, puis assembler ces deux volumes en RAID 0. On a également aussi le RAID 50, combinaison dur RAID 5 et du RAID 0 selon le même principe.

La gestion du RAID

Je vous parlais de différentes implémentations du RAID. En fait, le RAID n'est pas un programme en tant que soi, juste un ensemble de spécifications. Du coup chacun y va de sa sauce : il existe des implémentations libres et propriétaires, logicielles et matérielles. Les solutions matérielles se basent sur du matériel dédié (un contrôleur RAID), le système d'exploitation n'a donc pas à s'occuper de ça et le plus souvent ces solutions marchent out of the box, sans avoir besoin de configurer quoi que ce soit. Mais elles ont l'immense inconvénient d'être propriétaire dans leur quasi-totalité, et pour le coup il n'existe aucun standard. Dans certains cas, si votre contrôleur RAID rend l'âme, il vous faudra acquérir exactement le même modèle de contrôleur, sinon, peu importe que vos disques soient tous intacts, plus rien ne pourra les lire, et vous serez alors en légitime position d'être fort contrarié. À mon humble avis, le principal argument des RAIDs matériel auparavant était les meilleures performances. Aujourd'hui cet avantage est de plus en plus obsolète, car désormais les machines sont bien plus puissantes qu'il y a 15 ans et les programmes de RAID ont été nettement optimisés et stabilisés. Cette différence de performance est aujourd'hui presque intangible.

En pratique

J'ai hérité par un ami d'une tour de bureau. Elle est bien cool car elle contient une grande baie de disques et pas mal de ports SATA (bien entendu, vous pouvez faire votre RAID avec des disques branchés en USB si vous le souhaitez). J'ai donc décidé d'en faire un NAS fait main.

Choix des armes

J'ai donc initialement acheté 3 disques de 3 To chacun (des Western Digital Red, gamme dédiée justement aux usage en RAID) et j'ai opté pour un RAID 5 logiciel. Et sur Linux, le programme de RAID par excellence est mdadm. J'ai décidé de garder branché le disque dur d'origine (500 Go) mais de ne pas l'intégrer au RAID, il sert uniquement de disque de démarrage. Notez que si j'avais voulu optimiser les performances, j'aurais pu troquer ce disque pour un petit SSD, mais bon, je suis déjà content comme ça.

Par ailleurs, pour faire de la place dans la baie de disques, j'ai du déménager le disque de démarrage dans la baie frontale, celle destinée à accueillir les périphériques comme le lecteur optique.

Le 4ème disque du RAID, on en parlera plus tard. Je l'ai acheté bien après.

Pour ça j'ai utilisé un adaptateur 3,5 pouces vers 5,25 pouces bien pratique, qui m'a permis de fixer bien solidement le disque dur au lieu de le laisser se balader dans la tour.

Partitionnement et formatage

Du côté software, je me retrouve avec un disque sda de démarrage, et sdb, sdc et sdd des disques vierges prêts à être assemblés en RAID. Avant ça, j'ai besoin de les partitionner. J'utilise donc fdisk pour les trois disques à tour de rôle, je choisis une table de partitions GPT et j'y crée une unique partition de type "Linux RAID" (code 29 dans fdisk).

Création de l'assemblage RAID

C'est tout bête, ça tient en une seule ligne de commande :

mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1

Dans cette commande, j'indique que le nom du volume abstrait sera /dev/md0, que ce sera un RAID 5, qu'il comporte 3 disques et je lui précise les partitions que je veux utiliser.

Pour suivre l'évolution de la création de l'assemblage, jetez un coup d'oeil au fichier /proc/mdstat. Ce fichier sera votre nouvel ami, c'est lui qu'il faudra consulter dès que vous ferez une opération qui touche au RAID.

Puis j'ajoute l'assemblage à la configuration de mdadm pour que celui-ci me l'assemble au démarrage :

mdadm --detail --scan >> /etc/mdadm.conf

Puis il ne vous reste plus qu'à mettre votre système de fichier préféré sur le volume créé !

mkfs.ext4 /dev/md0

Pour que votre assemblage soit monté au démarrage, j'ajoute à mon /etc/fstab :

/dev/md0 /mnt/data ext4 defaults 0 0

Il ne faut pas confondre assemblage et montage, il s'agit de deux étapes lors de la connexion d'un RAID. On doit assembler un RAID afin qu'il soit reconnu comme un volume propre, puis on doit monter notre volume pour pouvoir lire et écrire dessus.

Enfin on monte le volume :

mkdir /mnt/data
mount /mnt/data

Ayé vous avez un RAID 5 qui fonctionne !

Il est recommandé de procéder régulièrement à des reconstruction de RAID, opération qui va vérifier la cohérence de l'assemblage. Il s'agit d'une opération transparente mais qui dure plusieurs heures et qui va se traduire par une forte augmentation de l'activité des disques. Pour ça il vous faudra lancer un petit programme sans arguments, raid-check, à un intervalle raisonnable, disons, toutes les semaines. Choisissez un horaire de faible activité, comme la nuit du samedi au dimanche à 3h du matin. Pour ça, faites vous plaisir, entre la crontab et les timers de systemd, on manque pas de solutions.

Ajout d'un nouveau disque à l'assemblage

Mon RAID 5 était constitué de 3 disques de 3 To ce qui nous fait 6 To exploitables, si vous avez bien suivi. 6 To, c'est un grand espace, il m'a suffi pendant presque 2 ans... Puis j'ai eu besoin de plus de place. J'ai donc racheté un autre disque (même modèle, même taille) que j'ai fourré dans ma tour. Je vous avoue que sur le coup, j'étais encore puceau au niveau extension de RAID, j'ai donc flippé énormément et j'ai fait une sauvegarde de mes 6 To sur divers disques externes que j'ai pu trouver dans ma caverne. Je vous raconte pas comme c'était pénible...

Petites observations à ce niveau :

1. Remarquez que l'ordre des disques dans le nommage des périphériques physiques (sdX) et tout sauf fixe. En théorie, il faut être préparé à ce que vos disques changent de noms. Votre petit sdb chéri que vous avez bordé et vu s'endormir dans le creux douillet de son lit un soir peut très bien vous trahir et s'appeler sdc au petit matin dès le prochain redémarrage. Bon c'est un peu exagéré, mais une chose est sure, il ne faut jamais faire confiance au nommage des périphériques physiques (c'est pour ça entre autres qu'il faut privilégier la désignation par UUID dans la fstab).
2. mdadm se fiche complètement du nommage de ses périphériques. Il utilise sa propre magie noire pour déterminer les membres d'un assemblages. En conclusion, ne vous tracassez pas pour retrouver le nom de vos disques de votre assemblage, mdadm, lui, s'y retrouvera toujours.

Cependant, faites quand même gaffe lorsque vous allez ajoutez votre nouveau disque dur. Par exemple chez moi, le nouveau disque s'est vu nommé sdb, tandis que les autres s'étaient vu relégués en sdc, sdd et sde. Faut juste le savoir et traiter les disques pour ce qu'ils sont, et non pas des étiquettes à trois lettres.

Tout ce que j'ai eu à faire, en définitive, a été de partitionner-formater mon nouveau disque ainsi que l'ont été ses aînés, puis j'ai lancé les deux commandes suivantes :

mdadm --add /dev/md0 /dev/sdb1
mdadm --grow --raid-devices=4 --backup-file=/root/grow\_md0.bak /dev/md0

La première va juste indiquer à mdadm qu'on lui ajoute un disque, mais sans plus. C'est la deuxième commande qui va lancer l'opération de reconstruction (rééquilibrage de l'assemblage). Opération qui dure plusieurs heures, donc suivez son déroulement dans /proc/mdstat.

Une fois que c'est terminé, il faut maintenant procéder à l'extension du système de fichier lui même. Et là vous priez pour avoir choisi un système de fichier pas trop stupide qui accepte ce genre d'opération. Rassurez-vous, ext4 le supporte très bien.

Il le supporte même tellement bien que vous pouvez le faire directement à chaud, sans démonter votre volume. Pour ça, premièrement, si vous utilisez une connexion SSH, ouvrez une session tmux. Il serait bête qu'un incident réseau de rien du tout vienne corrombre tout votre système de fichire tout de même. Puis il vous faudra exécuter :

resize2fs -p /dev/md0

Il va vous mettre en garde et ronchonner un tantinet que votre disque est toujours monté, mais écoutez, il s'en remettra, dans la vie on fait pas toujours ce qu'on veut. Les minutes passent, vous vous rongez les ongles, vous prenez un café, vous videz un pot de glace, et normalement, si tout se passe bien, le système de fichier aura été étendu à tout l'espace disponible sur l'assemblage. Félicitations !

Conclusion

J'ai rencontré beaucoup de monde m'ayant dit qu'ils préféraient rester éloigner autant que possible de RAID parce que ça leur faisait peur. En réalité, il n'y a rien d'effrayant là dedans. mdadm est un outil ma foi fort bien codé et les années ont prouvé qu'il était fiable. Il ne faut pas avoir peur du RAID. Enfin un peu quand même, faut pas faire n'importe quoi.

On ne vous le répétera jamais assez, mais il est indispensable de prendre conscience des enjeux des communications électroniques en clair. En effet, vous n'avez sûrement pas envie qu'un malandrin s'approprie vos messages et actions privées, comme votre correspondance avec votre médecin et vos opérat...

On ne vous le répétera jamais assez, mais il est indispensable de prendre conscience des enjeux des communications électroniques en clair. En effet, vous n'avez sûrement pas envie qu'un malandrin s'approprie vos messages et actions privées, comme votre correspondance avec votre médecin et vos opérations bancaires, données qu'ils pourrait retourner contre vous pour vous faire chanter, vous voler, ou tout bonnement vous faire du mal d'une manière quelconque. Il faut à tout prix préférer les communications chiffrées, et ce pour n'importe quel protocole.

Fort heureusement, aujourd'hui le chiffrement des flux est devenu en quelques sortes un standard grâce à l'essor des implémentation du protocole TLS et de ses variantes. Les protocoles anciens se sont pour la plupart dotés d'une surcouche sécurisée (HTTP, IMAP, SMTP, IRC) et les protocoles naissants sont aujourd'hui regardés de travers s'ils omettent la sécurité dans leurs cahiers des charges.

Malheureusement il existe encore des protocoles/programmes irréductibles qui continuent sans répit à laisser se balader à poil des paquets sur la toile. Ne leur jetons pas tout de suite la pierre, ou du moins pas trop fort, ce choix n'est pas toujours dénué de sens comme nous le verrons par la suite.

Ici comme dans pas mal d'articles sur Hashtagueule, il y a un déclencheur personnel du besoin qui fait l'objet du tutoriel en question. On est pas des hommes politiques, nous on vous parle de choses qu'on connaît. On a l'idée de parler de certaines choses en se frottant à des problèmes et en y trouvent des solutions. Je vais donc vous parler de l'outil Bitlbee, qui agit comme une passerelle entre divers messageries comme Jabber, Twitter, MSN et Yahoo d'un côté, et IRC de l'autre côté, ce qui permet de centraliser toutes ses messageries sur un simple client IRC. Pour ce faire, il simule un serveur IRC sur lequel se connectent les client qui veulent accéder aux services agrégé. Seulement, alors que la plupart des serveurs IRC proposent une connexion sécurisée, Bitlbee n'implante pas cette couche TLS. En partie parce que le serveur est destiné à être exécuté en local (donc pas grand risque d'intercepter les communications). Mais n'empêche que ça semble bizarre et qu'à priori ça bride pas mal les utilisations.

En réalisant ça, j'étais d'abord outré, et ça a même remis en question mon utilisation du programme. Cependant, j'ai trouvé une solution, qui est par ailleurs proposée par les développeurs. J'ai découvert un outil magique qui s'appelle stunnel, qui permet de transformer n'importe quel flux en clair par un flux chiffré à travers un certificat TLS. Pour ceux qui s'y connaissent un peu en serveur web, il s'agit du même principe qu'un reverse proxy comme le ferait un nginx ou un HAproxy, mais pour n'importe quel flux TCP (même si HAproxy est capable de gérer les flux TCP mais c'est moins marrant).

Du coup, il suffit de posséder un certificat adapté au nom de domaine qui pointe vers votre serveur (chose très facile en utilisant Let's Encrypt, pour peu que vous ayez un serveur web qui sert ce nom de domaine) et il vous est possible d'envelopper ce flux dans un tunnel TLS. Voici ce que j'ai ajouté dans ma configuration stunnel :

[bitlbee]
accept = 6697
connect = 6667
cert = /etc/letsencrypt/live/mon.domaine.tld/fullchain.pem
key = /etc/letsencrypt/live/mon.domaine.tld/privkey.pem

Le port 6667 est le port non sécurisé, et le port 6697 est le port sécurisé. Elle est pas belle la vie ?

De plus stunnel peut fonctionner dans l'autre sens, c'est à dire servir du contenu en clair à partir d'un canal sécurisé, ce qui est pratique quand derrière on a pas de client compatible avec TLS.

Bon, revenons sur les raisons qui poussent un programme à ne pas adopter la sécurisation des flux. Dans le cas de bitlbee, comme je l'ai dit plus tôt, c'est un serveur destiné à être atteint en local. De plus, certains projets choisissent de ne pas implémenter le chiffrement et de recommander explicitement des solutions comme stunnel pour ne pas être responsables d'une éventuelle faille dans leur implémentation. Et aussi parce que c'est gonflant de faire de la sécu quand le projet à l'origine n'a absolument pas de rapport, il faut le reconnaître.

On ne vous le répétera jamais assez, mais il est indispensable de prendre conscience des enjeux des communications électroniques en clair. En effet, vous n'avez sûrement pas envie qu'un malandrin s'approprie vos messages et actions privées, comme votre correspondance avec votre médecin et vos opérat...

On ne vous le répétera jamais assez, mais il est indispensable de prendre conscience des enjeux des communications électroniques en clair. En effet, vous n'avez sûrement pas envie qu'un malandrin s'approprie vos messages et actions privées, comme votre correspondance avec votre médecin et vos opérations bancaires, données qu'ils pourrait retourner contre vous pour vous faire chanter, vous voler, ou tout bonnement vous faire du mal d'une manière quelconque. Il faut à tout prix préférer les communications chiffrées, et ce pour n'importe quel protocole.

Fort heureusement, aujourd'hui le chiffrement des flux est devenu en quelques sortes un standard grâce à l'essor des implémentation du protocole TLS et de ses variantes. Les protocoles anciens se sont pour la plupart dotés d'une surcouche sécurisée (HTTP, IMAP, SMTP, IRC) et les protocoles naissants sont aujourd'hui regardés de travers s'ils omettent la sécurité dans leurs cahiers des charges.

Malheureusement il existe encore des protocoles/programmes irréductibles qui continuent sans répit à laisser se balader à poil des paquets sur la toile. Ne leur jetons pas tout de suite la pierre, ou du moins pas trop fort, ce choix n'est pas toujours dénué de sens comme nous le verrons par la suite.

Ici comme dans pas mal d'articles sur Hashtagueule, il y a un déclencheur personnel du besoin qui fait l'objet du tutoriel en question. On est pas des hommes politiques, nous on vous parle de choses qu'on connaît. On a l'idée de parler de certaines choses en se frottant à des problèmes et en y trouvent des solutions. Je vais donc vous parler de l'outil Bitlbee, qui agit comme une passerelle entre divers messageries comme Jabber, Twitter, MSN et Yahoo d'un côté, et IRC de l'autre côté, ce qui permet de centraliser toutes ses messageries sur un simple client IRC. Pour ce faire, il simule un serveur IRC sur lequel se connectent les client qui veulent accéder aux services agrégé. Seulement, alors que la plupart des serveurs IRC proposent une connexion sécurisée, Bitlbee n'implante pas cette couche TLS. En partie parce que le serveur est destiné à être exécuté en local (donc pas grand risque d'intercepter les communications). Mais n'empêche que ça semble bizarre et qu'à priori ça bride pas mal les utilisations.

En réalisant ça, j'étais d'abord outré, et ça a même remis en question mon utilisation du programme. Cependant, j'ai trouvé une solution, qui est par ailleurs proposée par les développeurs. J'ai découvert un outil magique qui s'appelle stunnel, qui permet de transformer n'importe quel flux en clair par un flux chiffré à travers un certificat TLS. Pour ceux qui s'y connaissent un peu en serveur web, il s'agit du même principe qu'un reverse proxy comme le ferait un nginx ou un HAproxy, mais pour n'importe quel flux TCP (même si HAproxy est capable de gérer les flux TCP mais c'est moins marrant).

Du coup, il suffit de posséder un certificat adapté au nom de domaine qui pointe vers votre serveur (chose très facile en utilisant Let's Encrypt, pour peu que vous ayez un serveur web qui sert ce nom de domaine) et il vous est possible d'envelopper ce flux dans un tunnel TLS. Voici ce que j'ai ajouté dans ma configuration stunnel :

[bitlbee]
accept = 6697
connect = 6667
cert = /etc/letsencrypt/live/mon.domaine.tld/fullchain.pem
key = /etc/letsencrypt/live/mon.domaine.tld/privkey.pem

Le port 6667 est le port non sécurisé, et le port 6697 est le port sécurisé. Elle est pas belle la vie ?

De plus stunnel peut fonctionner dans l'autre sens, c'est à dire servir du contenu en clair à partir d'un canal sécurisé, ce qui est pratique quand derrière on a pas de client compatible avec TLS.

Bon, revenons sur les raisons qui poussent un programme à ne pas adopter la sécurisation des flux. Dans le cas de bitlbee, comme je l'ai dit plus tôt, c'est un serveur destiné à être atteint en local. De plus, certains projets choisissent de ne pas implémenter le chiffrement et de recommander explicitement des solutions comme stunnel pour ne pas être responsables d'une éventuelle faille dans leur implémentation. Et aussi parce que c'est gonflant de faire de la sécu quand le projet à l'origine n'a absolument pas de rapport, il faut le reconnaître.

La vie privée sur Internet, c'est important, je crois que vous commencez à vous faire une bonne idée de notre opinion à ce sujet. Quand on vous en parlait sur Hashtagueule, certains auraient été tentés d'y voir uniquement une allusion aux ordinateurs. C'est vrai qu'on ne vous a parlé pour ainsi dire...

La vie privée sur Internet, c'est important, je crois que vous commencez à vous faire une bonne idée de notre opinion à ce sujet. Quand on vous en parlait sur Hashtagueule, certains auraient été tentés d'y voir uniquement une allusion aux ordinateurs. C'est vrai qu'on ne vous a parlé pour ainsi dire concrètement que de cette plateforme. Ce serait bien entendu avoir une gigantesque poutre dans l'œil que de croire qu'il ne faut se protéger que sur son PC. En effet, la quantité de données personnelles stockées dans les appareils mobiles est foutrement plus importante que sur nos ordinateurs. Imaginez, vous disposez d'un appareil qui ne vous lâche pas d'une semelle, qui sait exactement où vous vous trouvez, qui établit des liens vers d'autres personnes logées à la même enseigne, qui connait vos petits secrets, vos amis, votre famille, vos amours officiels ou secrets, qui est à la limite capable de détecter votre état de santé et vos paramètres biométriques. Couplez à cela le fait que les logiciels libres sont nettement moins répandus sur smartphone que sur ordinateur, ajoutez-y la législation corrompue et la centralisation des services, pour ne pas dire les portes dérobées qui font bonne figure, et vous vous rendez compte que vous avez un véritable œil de Moscou dans votre poche.

On va donc aujourd'hui parler mobile, plus particulièrement du domaine Android, cet OS grand public accordant le plus, à mon sens et celui de beaucoup d'autres, de pouvoir à l'utilisateur. Les esclaves propriétaires de téléphones Apple, désolé, nous compatissons, mais nous ne pouvons pas pour le moment vous fournir d'astuces significatives dans le domaine.

Android est développé par AOSP, un projet dans lequel Google est amplement majoritaire en implication. C'est un fait. Cependant, une partie de cet OS est en licence libre, ce qui permet à des OS basés sur Android (dites ROMs alternatives) de voir le jour. La version Google, quant à elle, est servie avec un ensemble de programmes destinés à se connecter aux services Google, afin de vous prodiguer un accès facile à votre compte Google et les services associés, pour masquer son vrai but, qui est de ramasser de la donnée sur vous. Pour des personnes aimant leurs services auto-hébergés ou qui ne souhaitent pas utiliser ces services, il est possible d'utiliser une ROM alternative pour supprimer les services Google.

Cependant, si on élimine les services Google, on se prive également de la boutique Google Play, ce qui peut en pénaliser plus d'un. Vous avez toujours la possibilité d'utiliser les dépôts standards F-Droid, mais cela reste un peu pauvre. Une autre solution serait d'installer le store d'Amazon, mais outre le fait que vous vous jetez vous même de Charybde en Scylla, ce n'est pas très conseillé car il y a plus d'applications piégées sur ce store, et moins de "bonnes" applications. Enfin, la solution la plus dangereuse serait de télécharger les apps à partir de sources non vérifiées comme il y en a des centaines sur Internet, ce qui est légalement douteux et catastrophique niveau sécurité, sans parler de l'absence de système de mise à jour. Point n'est besoin d'en dire plus, nous allons voir comment installer des applications du Google Play sans les services Google Play.

Niveau 0 : Installer une ROM alternative

Ce n'est pas le but de ce tutoriel, peut être pour une prochaine fois. La description de cette étape sera donc très sommaire, en attendant vous pourrez trouvez de très nombreux tutoriels pour le faire, ici on se concentrera en priorité sur la valeur ajoutée Hashtagueule.

Il vous faut d'abord choisir une ROM. Il y en a des dizaines, plus ou moins spécialisées. L'une des ROMs alternatives est CyanogenMod. Pour le moment, ma ROM de prédilection reste Dirty Unicorn, qui a un développement assez actif, qui intègre relativement rapidement des dernères nouveautés de la version Google d'Android, et qui a beaucoup de possibilités faciles d'accès de personnalisation d'interface. Pour information, cette ROM tourne impeccablement sur mon Nexus 5.

En partant d'un mobile sous Android Google, les étapes sont toujours les même :

1. rootage de l'appareil ;
2. installation d'un bootloader ;
3. copie de la ROM dans la mémoire de l'appareil ;
4. flash de la ROM.

Avant ces étapes, assurez vous de sauvegarder tout ce qu'il y a à sauvegarder, et notez votre identifiant Android, vous en aurez besoin plus tard. Pour ce faire, vous pouvez taper la combinaison *#*#8255#*#* sur le clavier du téléphone. Un texte va s'afficher, votre identifiant Android est à la ligne "Device ID", écrit sous la forme "android-votreidentifiant" (ce qui compte est après le tiret).

Vous pouvez également obtenir cet identifiant avec l'application Device ID. À télécharger sur le Google Play Store. Amusant quand on sait qu'on a besoin de ce numéro principalement pour éviter d'utiliser ce store.

Une fois votre ROM flashée, installez l'application F-Droid sur votre mobile. Cela vous permettra d'obtenir des applications libres, mais également de vous faire votre propre dépôt d'applications.

Niveau 1 : Télécharger les apps sur l'ordinateur

À ce niveau, l'important est de comprendre que vous téléchargerez les applications qui vous intéressent sur votre ordinateur en le faisant passer pour un appareil Android auprès de Google. Il y a plusieurs solutions pour y arriver. Personnellement, j'utilise l'extension Firefox APK Downloader dont le rôle est d'ajouter un bouton sur chaque page web du Google Play Store. Vous aurez besoin de configurer l'application en renseignant votre adresse de compte Google, votre mot de passe, et l'identifiant Android que vous avez noté plus tôt.

Notez le bouton "Download APK" permettant de télécharger directement l'application sur votre PC.

À partir de là, vous pouvez si vous le souhaitez installer directement l'application sur votre appareil à l'aide de la commande de débug d'Android :

adb install /chemin/vers/l/application/téléchargée.apk

Mais ce serait passer à côté de fonctionnalités intéressantes :

• En faisant ainsi, vous êtes obligé de brancher votre téléphone à chaque fois que vous voulez installer une application, ce qui implique d'avoir son câble et de ne pas avoir peur de ruiner le cycle de la batterie de votre appareil. Ou alors vous autorisez le débug par réseau, ce qui est vivement déconseillé car très peu sécurisé (il suffit de connaître l'IP de votre appareil pour que n'importe qui puisse installer n'importe quoi).
• Pas de système de mise à jour OTA : vous ne serez pas informé des mises à jour pouvant être cruciales, et vous devrez réinstaller manuellement chaque application en passant par l'ordinateur.

Niveau 2 : Mettre en place votre dépôt

Il est alors intéressant d'avoir un serveur sur lequel vous allez constituer votre dépôt privé. Pour cela, vous allez avoir besoin des programmes suivants :

• le gestionnaire de dépôt F-Droid (paquet fdroidserver disponible dans les dépôts Debian) qui va permettre au client F-Droid de se synchroniser sur votre serveur ;
• googleplayupdater, un petit outil bien pratique qui permet de mettre à jour toutes les applications APK dans un dossier donné ;
• un serveur web, Nginx est tout indiqué pour ce genre de tâches, sachant que l'on va servir uniquement du contenu statique.

Sur votre serveur, créez le dossier du dépôt, chez moi il s'agit du dossier /var/apk. Placez-vous dans ce répertoire et effectuez la commande suivante :

fdroid init

Cette commande va créer un certain nombre d'éléments, dont le dossier repo et le fichier config.py.

Intéressons-nous au fichier de configuration. Normalement les commentaires sont assez explicites. Voici à quoi peut ressembler votre fichier de configuration :

#!/usr/bin/env python2

mvn3 = "mvn"

gradle = "gradle"

repo_maxage = 0

repo_url = "http://bidule.machin.truc"
repo_name = "Repo perso de Raspbeguy"
repo_icon = "fdroid-icon.png"
repo_description = """
Comme j'utilise Dirty Unicorn tout nu sans les services Google play,
ben je suis dans l'obligation de magouiller...
"""

archive_older = 3
archive_url = "https://f-droid.org/archive"
archive_name = "My First FDroid Archive Demo"
archive_icon = "fdroid-icon.png"
archive_description = """
The repository of older versions of applications from the main demo repository.
"""

keydname = "CN=bidule.machin.truc, OU=F-Droid"

keyaliases['com.example.another.plugin'] = '@com.example.another'

# Wiki details
wiki_protocol = "http"
wiki_server = "server"
wiki_path = "/wiki/"
wiki_user = "login"
wiki_password = "1234"

update_stats = False

stats_to_carbon = False
carbon_host = '0.0.0.0'
carbon_port = 2003

build_server_always = False

char_limits = {
    'Summary': 50,
    'Description': 1500
}

Les lignes 9 à 15 de cet exemple sont les plus importantes. En fait, normalement, vous n'aurez pas à modifier les autres lignes pour que le dépôt fonctionne bien.

Il vous faut ensuite copier vos APK directement dans le dossier repo. Ensuite, à partir du dossier du dépôt (dans notre cas /var/apk), effectuez la commande suivante, que vous devrez refaire après chaque ajout d'application au dépôt :

fdroid update --create-metadata

Il faut maintenant mettre en place le serveur web afin que le dépôt soit accessible depuis votre appareil par le réseau. Créez donc un server block pour Nginx ressemblant à cela, dans le cas de l'utilisation de SSL/TLS, ce que je ne peux que vous recommander :

server{
  listen 80;
  listen [::]:80;
  server_name bidule.machin.truc;

  location ~ ^/.well-known/acme-challenge(/.*)?$ {
      root /etc/letsencrypt/webrootauth;
      default_type text/plain;
  }

  return 301 https://$server_name$request_uri;
}

server {
    listen 443;
    listen [::]:443;
    server_name bidule.machin.truc; 
    access_log /var/log/nginx/fdroid.access.log;
    error_log /var/log/nginx/fdroid.error.log;
    ssl on;
    ssl_certificate /etc/letsencrypt/live/machin.truc/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/machin.truc/privkey.pem;

    server_name_in_redirect off;

    root  /var/apk;

    location ~ ^/.well-known/acme-challenge(/.*)?$ {
        root /etc/letsencrypt/webrootauth;
        default_type text/plain;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

Les lignes 1 à 9 concernent la redirection de HTTP vers HTTPS. Vous reconnaîtrez certainement aux lignes 6 à 9 et 29 à 32 les instructions qu'on a introduites pour l'automatisation des renouvellements de certificats Let's Encrypt. Si ça ne vous dit rien, vous pouvez faire une cure de rappel par ici, c'est gratuit et ça vous met plein de belles choses dans la tête.

Rechargez Nginx, puis il faut maintenant tester sur votre appareil. Dans F-Droid, dans le menu en haut à droite, rendez vous dans la Gestion des dépôts, puis tapez le "+" pour ajouter un dépôt (duh...). Entrez https://bidule.machin.truc/repo en adresse de dépôt et rien pour l'empreinte (vous êtes le seul utilisateur de votre propre dépôt, vous savez déjà la provenance de ce qu'il y a dessus, de plus comme vous êtes déjà en connexion sécurisée, il n'y a plus beaucoup de risques).

Laissez mouliner quelques secondes, et paf, normalement vous avez un dépôt fonctionnel.

Le dépôt a bien été ajouté.

Exemple d'app ajoutée dans mon dépôt.

Une fois cette victoire confirmée, rappelez-vous le but initial de la manœuvre : avoir des applications qui se mettent à jour toutes seules comme des grandes.

Niveau 3 : Automatiser la mise à jour des apps

C'est ici que googleplayupdater entre en scène.

Pour disposer de cet outil, clonez le dépôt quelque part sur votre serveur (on se fiche de l’endroit, le programme sera installé ailleurs).

Installez le programme par la commande :

python setup.py install

Notez que vous aurez peut-être à installer au préalable l'outil de déploiement python-setuptools :

apt install python-setuptools  # si vous utilisez python2
apt install python3-setuptools # si vous utilisez python3

Attention, si vous utilisez Python 3 (c'est toujours recommandé de l'utiliser si possible et pas trop enquiquinant), vous devez installer manuellement une dépendance par la commande :

pip install https://pypi.python.org/packages/source/p/protobuf/protobuf-3.0.0a3.tar.gz#md5=6674fa7452ebf066b767075db96a7ee0

Ensuite, copiez et renommez le fichier config_example.py dans un endroit adéquat (par exemple /etc/googleplayupdater/config.py) et modifiez-le afin qu'il ressemble à ceci :

from __future__ import unicode_literals

LANG            = "en_US" # can be en_US, fr_FR, ...
ANDROID_ID      = "votre_identifiant_android"
GOOGLE_LOGIN    = 'adresse@machin.truc'
GOOGLE_PASSWORD = 'mdp_compte_google'
AUTH_TOKEN      = None

# force the user to edit this file
if ANDROID_ID == None or all([each == None for each in [GOOGLE_LOGIN, GOOGLE_PASSWORD]]):
    raise Exception("config.py not updated")

Bien sûr, adaptez les variables ANDROID_ID, GOOGLE_LOGIN et GOOGLE_PASSWORD avec ce que vous avez mis dans la configuration de votre extension Firefox...

Vous pouvez tester la configuration avec la commande suivante :

/usr/local/bin/googleplayupdater -c /etc/googleplayupdater/config.py -v /var/apk/repo

Si vous constatez que tout se passe bien, vous pouvez alors finaliser en créant un script cron update_apk que vous placerez dans /etc/cron.daily/ contenant ce code :

#!/bin/bash

GPUPD=/usr/local/bin/googleplayupdater
CONFIG=/etc/googleplayupdater/config.py
REPO=/var/apk
LOG_GPU=/var/log/gpupd.log
LOG_FDROID=/var/log/fdroid.log

echo -e "\n********** $(date)\n" >> $LOG_GPU

$GPUPD -c $CONFIG -v $REPO/repo >> $LOG_GPU 2>&1

cd $REPO

echo -e "\n********** $(date)\n" >> $LOG_FDROID

fdroid update --create-metadata >> $LOG_FDROID 2>&1

Ainsi, votre dépôt se mettra à jour tous les jours. Et votre appareil vous notifiera dès qu'une mise à jour sera disponible. Et vous n'avez rien de Google sur votre téléphone, c'est magnifique.

Inconvénients / améliorations possibles

Certaines application sont butées et requièrent la présence des services Google Play pour fonctionner, le cas le plus décevant étant Signal, que j'ai dû renoncer à utiliser. Peut-être que je trouverai un moyen de le compiler à ma sauce sans les dépendances qui m'embêtent.

Sinon, on pourrait travailler à trouver un moyen de télécharger les apps directement par le serveur, et ne pas être obligé de passer par Firefox. Ça pourra être l'objet d'un article ultérieur, si je trouve un moyen convainquant de le faire.

La vie privée sur Internet, c'est important, je crois que vous commencez à vous faire une bonne idée de notre opinion à ce sujet. Quand on vous en parlait sur Hashtagueule, certains auraient été tentés d'y voir uniquement une allusion aux ordinateurs. C'est vrai qu'on ne vous a parlé pour ainsi dire...

La vie privée sur Internet, c'est important, je crois que vous commencez à vous faire une bonne idée de notre opinion à ce sujet. Quand on vous en parlait sur Hashtagueule, certains auraient été tentés d'y voir uniquement une allusion aux ordinateurs. C'est vrai qu'on ne vous a parlé pour ainsi dire concrètement que de cette plateforme. Ce serait bien entendu avoir une gigantesque poutre dans l'œil que de croire qu'il ne faut se protéger que sur son PC. En effet, la quantité de données personnelles stockées dans les appareils mobiles est foutrement plus importante que sur nos ordinateurs. Imaginez, vous disposez d'un appareil qui ne vous lâche pas d'une semelle, qui sait exactement où vous vous trouvez, qui établit des liens vers d'autres personnes logées à la même enseigne, qui connait vos petits secrets, vos amis, votre famille, vos amours officiels ou secrets, qui est à la limite capable de détecter votre état de santé et vos paramètres biométriques. Couplez à cela le fait que les logiciels libres sont nettement moins répandus sur smartphone que sur ordinateur, ajoutez-y la législation corrompue et la centralisation des services, pour ne pas dire les portes dérobées qui font bonne figure, et vous vous rendez compte que vous avez un véritable œil de Moscou dans votre poche.

On va donc aujourd'hui parler mobile, plus particulièrement du domaine Android, cet OS grand public accordant le plus, à mon sens et celui de beaucoup d'autres, de pouvoir à l'utilisateur. Les esclaves propriétaires de téléphones Apple, désolé, nous compatissons, mais nous ne pouvons pas pour le moment vous fournir d'astuces significatives dans le domaine.

Android est développé par AOSP, un projet dans lequel Google est amplement majoritaire en implication. C'est un fait. Cependant, une partie de cet OS est en licence libre, ce qui permet à des OS basés sur Android (dites ROMs alternatives) de voir le jour. La version Google, quant à elle, est servie avec un ensemble de programmes destinés à se connecter aux services Google, afin de vous prodiguer un accès facile à votre compte Google et les services associés, pour masquer son vrai but, qui est de ramasser de la donnée sur vous. Pour des personnes aimant leurs services auto-hébergés ou qui ne souhaitent pas utiliser ces services, il est possible d'utiliser une ROM alternative pour supprimer les services Google.

Cependant, si on élimine les services Google, on se prive également de la boutique Google Play, ce qui peut en pénaliser plus d'un. Vous avez toujours la possibilité d'utiliser les dépôts standards F-Droid, mais cela reste un peu pauvre. Une autre solution serait d'installer le store d'Amazon, mais outre le fait que vous vous jetez vous même de Charybde en Scylla, ce n'est pas très conseillé car il y a plus d'applications piégées sur ce store, et moins de "bonnes" applications. Enfin, la solution la plus dangereuse serait de télécharger les apps à partir de sources non vérifiées comme il y en a des centaines sur Internet, ce qui est légalement douteux et catastrophique niveau sécurité, sans parler de l'absence de système de mise à jour. Point n'est besoin d'en dire plus, nous allons voir comment installer des applications du Google Play sans les services Google Play.

Niveau 0 : Installer une ROM alternative

Ce n'est pas le but de ce tutoriel, peut être pour une prochaine fois. La description de cette étape sera donc très sommaire, en attendant vous pourrez trouvez de très nombreux tutoriels pour le faire, ici on se concentrera en priorité sur la valeur ajoutée Hashtagueule.

Il vous faut d'abord choisir une ROM. Il y en a des dizaines, plus ou moins spécialisées. L'une des ROMs alternatives est CyanogenMod. Pour le moment, ma ROM de prédilection reste Dirty Unicorn, qui a un développement assez actif, qui intègre relativement rapidement des dernères nouveautés de la version Google d'Android, et qui a beaucoup de possibilités faciles d'accès de personnalisation d'interface. Pour information, cette ROM tourne impeccablement sur mon Nexus 5.

En partant d'un mobile sous Android Google, les étapes sont toujours les même :

1. rootage de l'appareil ;
2. installation d'un bootloader ;
3. copie de la ROM dans la mémoire de l'appareil ;
4. flash de la ROM.

Avant ces étapes, assurez vous de sauvegarder tout ce qu'il y a à sauvegarder, et notez votre identifiant Android, vous en aurez besoin plus tard. Pour ce faire, vous pouvez taper la combinaison *#*#8255#*#* sur le clavier du téléphone. Un texte va s'afficher, votre identifiant Android est à la ligne "Device ID", écrit sous la forme "android-votreidentifiant" (ce qui compte est après le tiret).

Vous pouvez également obtenir cet identifiant avec l'application Device ID. À télécharger sur le Google Play Store. Amusant quand on sait qu'on a besoin de ce numéro principalement pour éviter d'utiliser ce store.

Une fois votre ROM flashée, installez l'application F-Droid sur votre mobile. Cela vous permettra d'obtenir des applications libres, mais également de vous faire votre propre dépôt d'applications.

Niveau 1 : Télécharger les apps sur l'ordinateur

À ce niveau, l'important est de comprendre que vous téléchargerez les applications qui vous intéressent sur votre ordinateur en le faisant passer pour un appareil Android auprès de Google. Il y a plusieurs solutions pour y arriver. Personnellement, j'utilise l'extension Firefox APK Downloader dont le rôle est d'ajouter un bouton sur chaque page web du Google Play Store. Vous aurez besoin de configurer l'application en renseignant votre adresse de compte Google, votre mot de passe, et l'identifiant Android que vous avez noté plus tôt.

Notez le bouton "Download APK" permettant de télécharger directement l'application sur votre PC.

À partir de là, vous pouvez si vous le souhaitez installer directement l'application sur votre appareil à l'aide de la commande de débug d'Android :

adb install /chemin/vers/l/application/téléchargée.apk

Mais ce serait passer à côté de fonctionnalités intéressantes :

• En faisant ainsi, vous êtes obligé de brancher votre téléphone à chaque fois que vous voulez installer une application, ce qui implique d'avoir son câble et de ne pas avoir peur de ruiner le cycle de la batterie de votre appareil. Ou alors vous autorisez le débug par réseau, ce qui est vivement déconseillé car très peu sécurisé (il suffit de connaître l'IP de votre appareil pour que n'importe qui puisse installer n'importe quoi).
• Pas de système de mise à jour OTA : vous ne serez pas informé des mises à jour pouvant être cruciales, et vous devrez réinstaller manuellement chaque application en passant par l'ordinateur.

Niveau 2 : Mettre en place votre dépôt

Il est alors intéressant d'avoir un serveur sur lequel vous allez constituer votre dépôt privé. Pour cela, vous allez avoir besoin des programmes suivants :

• le gestionnaire de dépôt F-Droid (paquet fdroidserver disponible dans les dépôts Debian) qui va permettre au client F-Droid de se synchroniser sur votre serveur ;
• googleplayupdater, un petit outil bien pratique qui permet de mettre à jour toutes les applications APK dans un dossier donné ;
• un serveur web, Nginx est tout indiqué pour ce genre de tâches, sachant que l'on va servir uniquement du contenu statique.

Sur votre serveur, créez le dossier du dépôt, chez moi il s'agit du dossier /var/apk. Placez-vous dans ce répertoire et effectuez la commande suivante :

fdroid init

Cette commande va créer un certain nombre d'éléments, dont le dossier repo et le fichier config.py.

Intéressons-nous au fichier de configuration. Normalement les commentaires sont assez explicites. Voici à quoi peut ressembler votre fichier de configuration :

#!/usr/bin/env python2

mvn3 = "mvn"

gradle = "gradle"

repo_maxage = 0

repo_url = "http://bidule.machin.truc"
repo_name = "Repo perso de Raspbeguy"
repo_icon = "fdroid-icon.png"
repo_description = """
Comme j'utilise Dirty Unicorn tout nu sans les services Google play,
ben je suis dans l'obligation de magouiller...
"""

archive_older = 3
archive_url = "https://f-droid.org/archive"
archive_name = "My First FDroid Archive Demo"
archive_icon = "fdroid-icon.png"
archive_description = """
The repository of older versions of applications from the main demo repository.
"""

keydname = "CN=bidule.machin.truc, OU=F-Droid"

keyaliases['com.example.another.plugin'] = '@com.example.another'

# Wiki details
wiki_protocol = "http"
wiki_server = "server"
wiki_path = "/wiki/"
wiki_user = "login"
wiki_password = "1234"

update_stats = False

stats_to_carbon = False
carbon_host = '0.0.0.0'
carbon_port = 2003

build_server_always = False

char_limits = {
    'Summary': 50,
    'Description': 1500
}

Les lignes 9 à 15 de cet exemple sont les plus importantes. En fait, normalement, vous n'aurez pas à modifier les autres lignes pour que le dépôt fonctionne bien.

Il vous faut ensuite copier vos APK directement dans le dossier repo. Ensuite, à partir du dossier du dépôt (dans notre cas /var/apk), effectuez la commande suivante, que vous devrez refaire après chaque ajout d'application au dépôt :

fdroid update --create-metadata

Il faut maintenant mettre en place le serveur web afin que le dépôt soit accessible depuis votre appareil par le réseau. Créez donc un server block pour Nginx ressemblant à cela, dans le cas de l'utilisation de SSL/TLS, ce que je ne peux que vous recommander :

server{
  listen 80;
  listen [::]:80;
  server_name bidule.machin.truc;

  location ~ ^/.well-known/acme-challenge(/.*)?$ {
      root /etc/letsencrypt/webrootauth;
      default_type text/plain;
  }

  return 301 https://$server_name$request_uri;
}

server {
    listen 443;
    listen [::]:443;
    server_name bidule.machin.truc; 
    access_log /var/log/nginx/fdroid.access.log;
    error_log /var/log/nginx/fdroid.error.log;
    ssl on;
    ssl_certificate /etc/letsencrypt/live/machin.truc/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/machin.truc/privkey.pem;

    server_name_in_redirect off;

    root  /var/apk;

    location ~ ^/.well-known/acme-challenge(/.*)?$ {
        root /etc/letsencrypt/webrootauth;
        default_type text/plain;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

Les lignes 1 à 9 concernent la redirection de HTTP vers HTTPS. Vous reconnaîtrez certainement aux lignes 6 à 9 et 29 à 32 les instructions qu'on a introduites pour l'automatisation des renouvellements de certificats Let's Encrypt. Si ça ne vous dit rien, vous pouvez faire une cure de rappel par ici, c'est gratuit et ça vous met plein de belles choses dans la tête.

Rechargez Nginx, puis il faut maintenant tester sur votre appareil. Dans F-Droid, dans le menu en haut à droite, rendez vous dans la Gestion des dépôts, puis tapez le "+" pour ajouter un dépôt (duh...). Entrez https://bidule.machin.truc/repo en adresse de dépôt et rien pour l'empreinte (vous êtes le seul utilisateur de votre propre dépôt, vous savez déjà la provenance de ce qu'il y a dessus, de plus comme vous êtes déjà en connexion sécurisée, il n'y a plus beaucoup de risques).

Laissez mouliner quelques secondes, et paf, normalement vous avez un dépôt fonctionnel.

Le dépôt a bien été ajouté.

Exemple d'app ajoutée dans mon dépôt.

Une fois cette victoire confirmée, rappelez-vous le but initial de la manœuvre : avoir des applications qui se mettent à jour toutes seules comme des grandes.

Niveau 3 : Automatiser la mise à jour des apps

C'est ici que googleplayupdater entre en scène.

Pour disposer de cet outil, clonez le dépôt quelque part sur votre serveur (on se fiche de l’endroit, le programme sera installé ailleurs).

Installez le programme par la commande :

python setup.py install

Notez que vous aurez peut-être à installer au préalable l'outil de déploiement python-setuptools :

apt install python-setuptools  # si vous utilisez python2
apt install python3-setuptools # si vous utilisez python3

Attention, si vous utilisez Python 3 (c'est toujours recommandé de l'utiliser si possible et pas trop enquiquinant), vous devez installer manuellement une dépendance par la commande :

pip install https://pypi.python.org/packages/source/p/protobuf/protobuf-3.0.0a3.tar.gz#md5=6674fa7452ebf066b767075db96a7ee0

Ensuite, copiez et renommez le fichier config_example.py dans un endroit adéquat (par exemple /etc/googleplayupdater/config.py) et modifiez-le afin qu'il ressemble à ceci :

from __future__ import unicode_literals

LANG            = "en_US" # can be en_US, fr_FR, ...
ANDROID_ID      = "votre_identifiant_android"
GOOGLE_LOGIN    = 'adresse@machin.truc'
GOOGLE_PASSWORD = 'mdp_compte_google'
AUTH_TOKEN      = None

# force the user to edit this file
if ANDROID_ID == None or all([each == None for each in [GOOGLE_LOGIN, GOOGLE_PASSWORD]]):
    raise Exception("config.py not updated")

Bien sûr, adaptez les variables ANDROID_ID, GOOGLE_LOGIN et GOOGLE_PASSWORD avec ce que vous avez mis dans la configuration de votre extension Firefox...

Vous pouvez tester la configuration avec la commande suivante :

/usr/local/bin/googleplayupdater -c /etc/googleplayupdater/config.py -v /var/apk/repo

Si vous constatez que tout se passe bien, vous pouvez alors finaliser en créant un script cron update_apk que vous placerez dans /etc/cron.daily/ contenant ce code :

#!/bin/bash

GPUPD=/usr/local/bin/googleplayupdater
CONFIG=/etc/googleplayupdater/config.py
REPO=/var/apk
LOG_GPU=/var/log/gpupd.log
LOG_FDROID=/var/log/fdroid.log

echo -e "\n********** $(date)\n" >> $LOG_GPU

$GPUPD -c $CONFIG -v $REPO/repo >> $LOG_GPU 2>&1

cd $REPO

echo -e "\n********** $(date)\n" >> $LOG_FDROID

fdroid update --create-metadata >> $LOG_FDROID 2>&1

Ainsi, votre dépôt se mettra à jour tous les jours. Et votre appareil vous notifiera dès qu'une mise à jour sera disponible. Et vous n'avez rien de Google sur votre téléphone, c'est magnifique.

Inconvénients / améliorations possibles

Certaines application sont butées et requièrent la présence des services Google Play pour fonctionner, le cas le plus décevant étant Signal, que j'ai dû renoncer à utiliser. Peut-être que je trouverai un moyen de le compiler à ma sauce sans les dépendances qui m'embêtent.

Sinon, on pourrait travailler à trouver un moyen de télécharger les apps directement par le serveur, et ne pas être obligé de passer par Firefox. Ça pourra être l'objet d'un article ultérieur, si je trouve un moyen convainquant de le faire.

Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en t...

Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en toute simplicité et sans avoir besoin de faire perdre une après-midi à son petit neveux du côté de sa belle-mère, qui se trouve être administrateur système, afin qu'il lui répète une quinzaine de fois les étapes de création et de validation d'un certificat en bonne et due forme. Ah, la famille...

Mais tout d’abord, je vous souhaite à tous une bonne année 211 - 25 ! Au niveau personnel, je vous souhaite tout le bonheur que vous méritez, tant sur le plan professionnel/scolaire qu'avec votre famille/amis/béguin divers. Instruisez-vous, soyez curieux, incitez vos proches à la sagesse, et bien sûr, restez vous-même gentils.

Au niveau citoyen, je souhaite comme toujours une prise de conscience collective sur cette cage en or qu'est devenue aujourd'hui la vie sur les internets, et une plus grande sagesse de nos têtes décideuses (à défaut d'être pensantes) à propos de la réalité numérique, qu'elles n'ont toujours pas bien intégrée.

Enfin, revenons à notre tutoriel. Au cours du mois dernier, vous l'avez peut-être remarqué, le certificat de notre blog (ainsi que les certificats de nos services internes, mais ça c'est nos oignons) ont changé d'autorité de certification. Nous sommes passés d'un certificat Gandi, offert avec notre nom de domaine, à un certificat Let's Encrypt, grâce à l'ouverture de ce service en bêta publique. Pourquoi avons-nous changé ? Et bien, d'abord, depuis le temps que nous vous en parlions, il aurait été ironique que nous n'utilisions pas le système Let's Encrypt. Ensuite, cette manière de procéder n'est pas sans avantages pour un administrateur système, principalement pour les raisons suivantes :

• Gain de temps global, même pour la première utilisation ;
• Possibilité de créer un seul certificat pour plusieurs domaines ;
• Automatisation très poussée des différentes étapes, permettant l'écriture de scripts pour les renouvèlements.

J'avoue qu'avant la bêta publique et la possibilité de mettre vraiment les mains dans le cambouis, je n'avais aucune idée du fonctionnement, même basique, de ce service. Je n'ai même jamais personnellement manifesté d'attirance particulière envers les technologies de sécurité. En fait, son fonctionnement théorique est très simple, et permet même, à mon sens, de se rendre bien compte du processus de certification SSL dans sa globalité.

Principe de la vérification d'identité

Lors de la création d'un certificat, on doit suivre un protocole invariant de l'autorité de certification :

1. On crée une clef secrète (ou on utilise une clef générée antérieurement).
2. À partir de cette clef secrète, on génère une demande de certification (contenant une clef publique et des informations sur l'identité de l'entité à certifier).
3. On soumet cette demande à l'autorité de certification désirée, qui génère et signe un certificat, ce qui dit aux outils des utilisateurs de votre service qu'il s'agit bien de vous, car il fait confiance à l'autorité de certification.

Les deux premières étapes sont instantanées ; cependant, la dernière étape prends traditionnellement plus de temps, car l'autorité de certification doit s'assurer de l'identité du domaine qu'elle doit certifier. Chez les autorités classiques, il s'agit souvent de fournir des pièces d'identités, ou de répondre à un mail auquel seul le possesseur du domaine peut accéder (du type admin@example.com).

Let's Encrypt prends en charge ces 3 étapes (il faut reconnaitre que c'est très facile d'automatiser les 2 premières) en passant par un utilitaire chargé de communiquer avec le serveur de son autorité de certification.

Processus de vérification d'identité

1. Une fois la clef et la demande de certificat générées, l'exécutable local communique au serveur http un code de vérification à rendre accessible par le serveur de certification.
2. L'utilitaire demande à l'autorité de certification de procéder à une vérification d'identité en envoyant la demande de certificat et lui communique le code servi par le serveur http à tester.
3. Le serveur de certification accède au serveur http en utilisant le système DNS
4. L'autorité de certification accepte l'identité et transfert le certificat.
5. L'utilitaire met le certificat généré à disposition des services de l’utilisateur.

Ainsi, le processus de création du certificat ne prends en tout et pour tout que quelques dizaines de secondes. Cependant, par cette méthode, on est contraint de mettre en service, au moins temporairement, un service web pour chaque domaine à tester, ce qui est gênant pour des domaines qui ne sont pas destinés à pointer sur un site web.

Configurer son serveur web

Let's Encrypt met à disposition des "extensions" lui permettant de communiquer tout seul au serveur web les informations pour l'étape de la vérification d'identité. Cependant, j'utilise Nginx, et à ce jour seul Apache dispose d'une extension stable. Il existe une extension expérimentale pour Nginx mais je n'ai pas su m'en servir convenablement, ou alors j'ai eu la flemme de comprendre comment elle marchait. De toute façon, selon les retours utilisateurs et les forums, la méthode générique (dite du webroot) est la plus utilisée, c'est donc celle qui sera présentée, et vous verrez, ce ne sera pas bien compliqué.

Tout d'abord, il faut définir le dossier qui sera mis à disposition par le serveur web. Par exemple, pour pouvez créer et choisir l'emplacement /var/www/webrootauth.

Vous devez ensuite modifier la configuration de chaque domaine que vous souhaitez faire certifier. Vous avez le droit à 100 domaines couverts par votre certificat, vous avez donc de la marge, et vous auriez tort de vous priver. Sous Nginx, vous devez ajouter au sein de chaque server block :

location ~ ^/.well-known/acme-challenge(/.*)?$ {
    root /var/www/webrootauth;
    default_type text/plain;
}

Sans oublier de recharger Nginx :

service nginx restart

ou bien, selon votre distribution Linux :

systemctl restart nginx

Pour information, cela demande à Nginx de servir le contenu de /var/www/webrootauth à l'adresse http://example.com/.well-known/acme-challenge/, adresse qui sela utilisée par l'autorité de certification.

Installer l'utilitaire

EDIT : C'était prévisible, maintenant quelques distributions intègrent Let's Encrypt dans leurs dépôts. Cette méthode est donc à privilégier par rapport à la méthode ci dessous.

Il faut maintenant télécharger l'exécutable mis à disposition par Let's Encrypt. Pour cela, vous allez avoir besoin de Git, veillez donc à ce qu'il soit installé sur votre machine.

Devenez super-utilisateur :

sudo su -

Puis clonez le dépôt du projet :

git clone https://github.com/letsencrypt/letsencrypt /root/letsencrypt

Configurer Let's Encrypt

Il est possible d'exécuter Let's Encrypt à la sauvage sans fichier de configuration, uniquement avec des paramètres long comme mon bras. Il est néanmoins plus propre d'écrire son fichier de configuration, cela donne des scripts plus propres et un historique bash plus clair. Et comme ça vous n'avez pas des tonnes de lignes de commandes à retenir en cas de perte de vos scripts :)

Un fichier de configuration Lets Encrypt ressemble à ceci :

rsa-key-size = 4096
server = https://acme-v01.api.letsencrypt.org/directory
email = votreadresse@domaine.truc
authenticator = webroot
webroot-path = /var/www/webrootauth
text = True
renew-by-default = True
agree-tos = True
domains = hashtagueule.fr,mail.hashtagueule.fr,wiki.hashtagueule.fr,mysql.hashtagueule.fr,znc.hashtagueule.fr,ttrss.hashtagueule.fr

Petite explication :

• rsa-key-size : la taille de la clef, on l'a mis au maximum, parce qu'on est des gros bourrins. Sachez que la génération d'une clef 4096 bits prends plus de temps, mais elle n'est générée qu'à la première exécution.
• server : l'adresse du serveur de certification. Ça ne sert à rien de le changer.
• email : l'adresse e-mail de votre compte Let's Encrypt (s'il n'existe pas, il sera créé automatiquement, pas d’inquiétude).
• authenticator : la méthode de vérification d'identité, on a dit qu'on choisissait la méthode webroot.
• webroot-path : doit correspondre au chemin choisi précédemment.
• text : indique que l'on souhaite exécuter l'outil en lignes de commandes, pratique pour les scripts et permet de tout exécuter sans intéraction (un mode pseudo-graphique existe mais n'est pas pratique).
• renew-by-default : indique que les certificats existants doivent être renouvelés.
• agree-tos : indique que vous acceptez la paperasse lié à l'utilisation des certificats, à lire quelque part sur leur site, mais bon, rien de bien méchant.
• domains : là, vous devez indiquer tous les domaines que doit couvrir le certificat qui va être généré, séparés par une virgule.

Vous placerez ce fichier quelque part d'accessible. Par exemple, vous pouvez le placer dans /root/le-config/cli.ini.

Générer ponctuellement le certificat

Tout est en place pour la génération de votre premier certificat, la tension monte, je vous sens tout excité. Allez, lancez-vous, en voiture Simone. Pour générer votre certificat, en tant que super-utilisateur, exécutez la commande suivante :

/root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini

Laissez mijoter quelques instants. La première fois, des dépendances nécessaires vont s'installer, il va configurer deux trois trucs, et finalement faire le boulot.

Normalement, à la fin, vous allez avoir un message vous félicitant du succès de l'opération. Bravo, vous avez un certificat Let's Encrypt :)

Vous pourrez ensuite configurer votre serveur web pour utiliser ce certificat. Sous Nginx, vous préciserez dans vos server blocks :

listen 443;
listen [::]:443;
ssl on;
ssl_certificate /etc/letsencrypt/live/hashtagueule.fr/fullchain.pem;
ssl_certificate\_key /etc/letsencrypt/live/hashtagueule.fr/privkey.pem;

Bien sûr, vous remplacerez hashtagueule.fr par le nom de votre domaine principal. Vérifiez en regardant le nom du dossier à cet emplacement.

Vous pouvez ensuite recharger Nginx, et si tout ce passe bien, vous avez un site sécurisé Let's Encrypt.

Renouvellement automatique

Les certificats générés par Let's Encrypt ont une validité de 90 jours. C'est court, et c'est un fil à la patte de devoir tous les 3 mois demander un renouvellement de certificat. Heureusement, il y a Cron.

Cron est un service sur votre machine qui va se charger d'exécuter des tâches à intervalle régulier. Tous ce que vous avez à faire, c'est d'écrire un script à fournir à cron. Ce script ressemblera à ça :

#!/bin/bash

la_cert_dir=/etc/letsencrypt/live/hashtagueule.fr

/root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini 1> /dev/null

# nginx
service nginx reload

# Vous pouvez également scripter les opération à suivre
# pour d'autres services, par exemple votre serveur mail.

# Envoi d'un mail de notification à l'administrateur
mail -a "From: Agent de certification Hashtagueule <letsencrypt@hashtagueule.fr>" -a "Content-Type: text/plain; charset=UTF-8" -s "Renouvellement des certificats" votreadresse@domaine.truc << EOF
Bonjour,

Le certificat des services Hashtagueule a été renouvelé et couvre actuellement les domaines suivants :

$(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -noout -text | grep DNS | sed 's/, /\n/g' | cut -d: -f2)

Dates de validité :

$(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -dates -noout | cut -d= -f2)

Pour rappel, les certificats délivrés par Let's Encrypt ont toujours une validité de 3 mois. Tâchez donc de définir une période de renouvellement inférieure à cette durée.
Il est à noter également que l'autorité Let's Encrypt ne délivre qu'un maximum de 5 certificats pour le même domaine par semaine. Renouvelez donc avec précaution.

Bonne journée.
EOF

Ce script va renouveler le certificat et vous envoyer un mail de notification comportant les nouvelles dates de validité et les domaines concernés. Classe, non ?

Il vous reste à rendre ce script exécutable et à le placer dans /etc/cron.monthly afin de l'exécuter tous les mois.

Limitations

Comme indiqué précédemment, les domaines à certifier doivent être servis par un serveur web, au moins pour la durée de la vérification d'identité.

D'autre part, évitez de générer trop de certificats, car vous êtes limités à 5 renouvèlements par semaine. En régime permanent ça ne pose pas de problème, mais je me suis déjà fait avoir lors de mes tests...

Voilà, j'espère que ce tutoriel vous aura été utile, et j'espère aussi voir fleurir une multitude de sites sécurisés.

Désormais, vous n'avez plus aucune excuse.

Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en t...

Bonjour à tous ! Nous allons débuter l'année avec un tutoriel sur la prise en main de Let's Encrypt, l'autorité de certification censée révolutionner l'usage de la technologie SSL par sa facilité d'usage, et qui doit permettre à Madame Michu de sécuriser son petit blog de cuisine traditionnelle en toute simplicité et sans avoir besoin de faire perdre une après-midi à son petit neveux du côté de sa belle-mère, qui se trouve être administrateur système, afin qu'il lui répète une quinzaine de fois les étapes de création et de validation d'un certificat en bonne et due forme. Ah, la famille...

Mais tout d’abord, je vous souhaite à tous une bonne année 211 - 25 ! Au niveau personnel, je vous souhaite tout le bonheur que vous méritez, tant sur le plan professionnel/scolaire qu'avec votre famille/amis/béguin divers. Instruisez-vous, soyez curieux, incitez vos proches à la sagesse, et bien sûr, restez vous-même gentils.

Au niveau citoyen, je souhaite comme toujours une prise de conscience collective sur cette cage en or qu'est devenue aujourd'hui la vie sur les internets, et une plus grande sagesse de nos têtes décideuses (à défaut d'être pensantes) à propos de la réalité numérique, qu'elles n'ont toujours pas bien intégrée.

Enfin, revenons à notre tutoriel. Au cours du mois dernier, vous l'avez peut-être remarqué, le certificat de notre blog (ainsi que les certificats de nos services internes, mais ça c'est nos oignons) ont changé d'autorité de certification. Nous sommes passés d'un certificat Gandi, offert avec notre nom de domaine, à un certificat Let's Encrypt, grâce à l'ouverture de ce service en bêta publique. Pourquoi avons-nous changé ? Et bien, d'abord, depuis le temps que nous vous en parlions, il aurait été ironique que nous n'utilisions pas le système Let's Encrypt. Ensuite, cette manière de procéder n'est pas sans avantages pour un administrateur système, principalement pour les raisons suivantes :

• Gain de temps global, même pour la première utilisation ;
• Possibilité de créer un seul certificat pour plusieurs domaines ;
• Automatisation très poussée des différentes étapes, permettant l'écriture de scripts pour les renouvèlements.

J'avoue qu'avant la bêta publique et la possibilité de mettre vraiment les mains dans le cambouis, je n'avais aucune idée du fonctionnement, même basique, de ce service. Je n'ai même jamais personnellement manifesté d'attirance particulière envers les technologies de sécurité. En fait, son fonctionnement théorique est très simple, et permet même, à mon sens, de se rendre bien compte du processus de certification SSL dans sa globalité.

Principe de la vérification d'identité

Lors de la création d'un certificat, on doit suivre un protocole invariant de l'autorité de certification :

1. On crée une clef secrète (ou on utilise une clef générée antérieurement).
2. À partir de cette clef secrète, on génère une demande de certification (contenant une clef publique et des informations sur l'identité de l'entité à certifier).
3. On soumet cette demande à l'autorité de certification désirée, qui génère et signe un certificat, ce qui dit aux outils des utilisateurs de votre service qu'il s'agit bien de vous, car il fait confiance à l'autorité de certification.

Les deux premières étapes sont instantanées ; cependant, la dernière étape prends traditionnellement plus de temps, car l'autorité de certification doit s'assurer de l'identité du domaine qu'elle doit certifier. Chez les autorités classiques, il s'agit souvent de fournir des pièces d'identités, ou de répondre à un mail auquel seul le possesseur du domaine peut accéder (du type admin@example.com).

Let's Encrypt prends en charge ces 3 étapes (il faut reconnaitre que c'est très facile d'automatiser les 2 premières) en passant par un utilitaire chargé de communiquer avec le serveur de son autorité de certification.

Processus de vérification d'identité

1. Une fois la clef et la demande de certificat générées, l'exécutable local communique au serveur http un code de vérification à rendre accessible par le serveur de certification.
2. L'utilitaire demande à l'autorité de certification de procéder à une vérification d'identité en envoyant la demande de certificat et lui communique le code servi par le serveur http à tester.
3. Le serveur de certification accède au serveur http en utilisant le système DNS
4. L'autorité de certification accepte l'identité et transfert le certificat.
5. L'utilitaire met le certificat généré à disposition des services de l’utilisateur.

Ainsi, le processus de création du certificat ne prends en tout et pour tout que quelques dizaines de secondes. Cependant, par cette méthode, on est contraint de mettre en service, au moins temporairement, un service web pour chaque domaine à tester, ce qui est gênant pour des domaines qui ne sont pas destinés à pointer sur un site web.

Configurer son serveur web

Let's Encrypt met à disposition des "extensions" lui permettant de communiquer tout seul au serveur web les informations pour l'étape de la vérification d'identité. Cependant, j'utilise Nginx, et à ce jour seul Apache dispose d'une extension stable. Il existe une extension expérimentale pour Nginx mais je n'ai pas su m'en servir convenablement, ou alors j'ai eu la flemme de comprendre comment elle marchait. De toute façon, selon les retours utilisateurs et les forums, la méthode générique (dite du webroot) est la plus utilisée, c'est donc celle qui sera présentée, et vous verrez, ce ne sera pas bien compliqué.

Tout d'abord, il faut définir le dossier qui sera mis à disposition par le serveur web. Par exemple, pour pouvez créer et choisir l'emplacement /var/www/webrootauth.

Vous devez ensuite modifier la configuration de chaque domaine que vous souhaitez faire certifier. Vous avez le droit à 100 domaines couverts par votre certificat, vous avez donc de la marge, et vous auriez tort de vous priver. Sous Nginx, vous devez ajouter au sein de chaque server block :

location ~ ^/.well-known/acme-challenge(/.*)?$ {
    root /var/www/webrootauth;
    default_type text/plain;
}

Sans oublier de recharger Nginx :

service nginx restart

ou bien, selon votre distribution Linux :

systemctl restart nginx

Pour information, cela demande à Nginx de servir le contenu de /var/www/webrootauth à l'adresse http://example.com/.well-known/acme-challenge/, adresse qui sela utilisée par l'autorité de certification.

Installer l'utilitaire

EDIT : C'était prévisible, maintenant quelques distributions intègrent Let's Encrypt dans leurs dépôts. Cette méthode est donc à privilégier par rapport à la méthode ci dessous.

Il faut maintenant télécharger l'exécutable mis à disposition par Let's Encrypt. Pour cela, vous allez avoir besoin de Git, veillez donc à ce qu'il soit installé sur votre machine.

Devenez super-utilisateur :

sudo su -

Puis clonez le dépôt du projet :

git clone https://github.com/letsencrypt/letsencrypt /root/letsencrypt

Configurer Let's Encrypt

Il est possible d'exécuter Let's Encrypt à la sauvage sans fichier de configuration, uniquement avec des paramètres long comme mon bras. Il est néanmoins plus propre d'écrire son fichier de configuration, cela donne des scripts plus propres et un historique bash plus clair. Et comme ça vous n'avez pas des tonnes de lignes de commandes à retenir en cas de perte de vos scripts :)

Un fichier de configuration Lets Encrypt ressemble à ceci :

rsa-key-size = 4096
server = https://acme-v01.api.letsencrypt.org/directory
email = votreadresse@domaine.truc
authenticator = webroot
webroot-path = /var/www/webrootauth
text = True
renew-by-default = True
agree-tos = True
domains = hashtagueule.fr,mail.hashtagueule.fr,wiki.hashtagueule.fr,mysql.hashtagueule.fr,znc.hashtagueule.fr,ttrss.hashtagueule.fr

Petite explication :

• rsa-key-size : la taille de la clef, on l'a mis au maximum, parce qu'on est des gros bourrins. Sachez que la génération d'une clef 4096 bits prends plus de temps, mais elle n'est générée qu'à la première exécution.
• server : l'adresse du serveur de certification. Ça ne sert à rien de le changer.
• email : l'adresse e-mail de votre compte Let's Encrypt (s'il n'existe pas, il sera créé automatiquement, pas d’inquiétude).
• authenticator : la méthode de vérification d'identité, on a dit qu'on choisissait la méthode webroot.
• webroot-path : doit correspondre au chemin choisi précédemment.
• text : indique que l'on souhaite exécuter l'outil en lignes de commandes, pratique pour les scripts et permet de tout exécuter sans intéraction (un mode pseudo-graphique existe mais n'est pas pratique).
• renew-by-default : indique que les certificats existants doivent être renouvelés.
• agree-tos : indique que vous acceptez la paperasse lié à l'utilisation des certificats, à lire quelque part sur leur site, mais bon, rien de bien méchant.
• domains : là, vous devez indiquer tous les domaines que doit couvrir le certificat qui va être généré, séparés par une virgule.

Vous placerez ce fichier quelque part d'accessible. Par exemple, vous pouvez le placer dans /root/le-config/cli.ini.

Générer ponctuellement le certificat

Tout est en place pour la génération de votre premier certificat, la tension monte, je vous sens tout excité. Allez, lancez-vous, en voiture Simone. Pour générer votre certificat, en tant que super-utilisateur, exécutez la commande suivante :

/root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini

Laissez mijoter quelques instants. La première fois, des dépendances nécessaires vont s'installer, il va configurer deux trois trucs, et finalement faire le boulot.

Normalement, à la fin, vous allez avoir un message vous félicitant du succès de l'opération. Bravo, vous avez un certificat Let's Encrypt :)

Vous pourrez ensuite configurer votre serveur web pour utiliser ce certificat. Sous Nginx, vous préciserez dans vos server blocks :

listen 443;
listen [::]:443;
ssl on;
ssl_certificate /etc/letsencrypt/live/hashtagueule.fr/fullchain.pem;
ssl_certificate\_key /etc/letsencrypt/live/hashtagueule.fr/privkey.pem;

Bien sûr, vous remplacerez hashtagueule.fr par le nom de votre domaine principal. Vérifiez en regardant le nom du dossier à cet emplacement.

Vous pouvez ensuite recharger Nginx, et si tout ce passe bien, vous avez un site sécurisé Let's Encrypt.

Renouvellement automatique

Les certificats générés par Let's Encrypt ont une validité de 90 jours. C'est court, et c'est un fil à la patte de devoir tous les 3 mois demander un renouvellement de certificat. Heureusement, il y a Cron.

Cron est un service sur votre machine qui va se charger d'exécuter des tâches à intervalle régulier. Tous ce que vous avez à faire, c'est d'écrire un script à fournir à cron. Ce script ressemblera à ça :

#!/bin/bash

la_cert_dir=/etc/letsencrypt/live/hashtagueule.fr

/root/letsencrypt/letsencrypt-auto certonly --config /root/le-config/cli.ini 1> /dev/null

# nginx
service nginx reload

# Vous pouvez également scripter les opération à suivre
# pour d'autres services, par exemple votre serveur mail.

# Envoi d'un mail de notification à l'administrateur
mail -a "From: Agent de certification Hashtagueule <letsencrypt@hashtagueule.fr>" -a "Content-Type: text/plain; charset=UTF-8" -s "Renouvellement des certificats" votreadresse@domaine.truc << EOF
Bonjour,

Le certificat des services Hashtagueule a été renouvelé et couvre actuellement les domaines suivants :

$(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -noout -text | grep DNS | sed 's/, /\n/g' | cut -d: -f2)

Dates de validité :

$(openssl x509 -in /etc/letsencrypt/live/hashtagueule.fr/cert.pem -dates -noout | cut -d= -f2)

Pour rappel, les certificats délivrés par Let's Encrypt ont toujours une validité de 3 mois. Tâchez donc de définir une période de renouvellement inférieure à cette durée.
Il est à noter également que l'autorité Let's Encrypt ne délivre qu'un maximum de 5 certificats pour le même domaine par semaine. Renouvelez donc avec précaution.

Bonne journée.
EOF

Ce script va renouveler le certificat et vous envoyer un mail de notification comportant les nouvelles dates de validité et les domaines concernés. Classe, non ?

Il vous reste à rendre ce script exécutable et à le placer dans /etc/cron.monthly afin de l'exécuter tous les mois.

Limitations

Comme indiqué précédemment, les domaines à certifier doivent être servis par un serveur web, au moins pour la durée de la vérification d'identité.

D'autre part, évitez de générer trop de certificats, car vous êtes limités à 5 renouvèlements par semaine. En régime permanent ça ne pose pas de problème, mais je me suis déjà fait avoir lors de mes tests...

Voilà, j'espère que ce tutoriel vous aura été utile, et j'espère aussi voir fleurir une multitude de sites sécurisés.

Désormais, vous n'avez plus aucune excuse.