Sécurisez vos bitcoins en 1 heure, sans connaissances, sans prise de tête, maintenant !

Je vous connais ! Ça fait des mois que vos bitcoins traînent sur un échange ou une appli mobile. Toutes les semaines, vous entendez parler d’une fermeture ou d’un piratage, et vous vous dites : “Promis, demain je m’en occupe !”. Eh bien figurez-vous que demain, c’est aujourd’hui, maintenant, tout de suite, allez, pas d’excuse.

Dans ce guide, je vous explique :

  1. comment créer un cold storage, pour sécuriser vos bitcoins
  2. comment créer un wallet en watching-only, pour consulter votre portefeuille et recevoir des bitcoins sans risque, depuis votre ordinateur / tablette / téléphone
  3. comment signer des transactions, pour retirer des bitcoins de votre cold storage

Vous avez besoin :

  • d’un ordinateur (sous Windows, macOS ou Linux)
  • d’un lieu calme, à l’abri des regards
  • d’une clé USB d’au moins 2 Go
  • d’un morceau de papier et d’un stylo
  • d’une heure de libre

Chaque étape est détaillée et illustrée, rassurez-vous, la procédure est bien plus simple et rapide (1 h maximum) que la longueur de cet article pourrait le laisser présager !

Créer un cold storage avec Electrum

Un cold storage ? Qu’est-ce que c’est ?

Un cold storage est un wallet qui n’a jamais été exposé à internet. L’objectif est de le rendre inaccessible à un pirate.

Pourquoi ne pas simplement me déconnecter d’internet avant d’accéder à mon wallet ?

Ce n’est pas suffisant ! Les logiciels espions s’accommodent très bien d’une coupure d’internet, ils gardent en mémoire ce qui s’affiche à votre écran et ce que vous tapez au clavier puis l’envoient au pirate lorsque vous vous reconnectez.

Mais mon ordinateur est sûr, je fais attention, je n’ai jamais eu de virus !

On parie tous vos bitcoins ? Le temps des virus visibles et destructeurs est révolu. Le piratage est devenu une véritable industrie, gérée par de grands groupes mafieux. Ces criminels disposent de ressources colossales et sont prêts à acheter des failles de sécurité pour des montants faramineux, car obtenir l’accès prolongé à l’ordinateur d’un particulier est très rentable : récupération d’informations bancaires, d’identifiants en tout genre (Netflix, Spotify, Amazon, etc.), envoi massif de spams, attaques distribuées, utilisation de la machine comme proxy, utilisation des capacités de calcul (pour miner des cryptos par exemple ?), et bien sûr vol de wallets !

Au-delà des virus, Windows et macOS sont de complexes boîtes hermétiquement fermées, sur lesquelles sont installées d’autres boîtes tout aussi hermétiques, et qui font peut-être bien d’autres choses que celles qu’on leur demande. Elles laissent (volontairement ou non) fuiter tout un tas d’informations à notre insu.

Pour toutes ces raisons, quelles que soient les précautions que nous pouvons prendre, il est impossible d’affirmer qu’un wallet est raisonnablement sûr sur un ordinateur connecté à internet.

Bon, mais les plateformes sont fiables, non ?

Pas vraiment :

Je n’ai pas tout listé !

Avec l’envolée du cours des cryptomonnaies et de leur nombre d’utilisateurs, les plateformes d’échange sont devenues des cibles majeures de piratage. Vous ne devez y laisser que le strict minimum.

C’est contraignant ?

La sécurité vient souvent au détriment de la commodité. Mais l’idée n’est pas de ne rien laisser sur les plateformes et sur le wallet que vous utilisez au quotidien. Il s’agit de séparer votre épargne de votre compte courant. Gardez un montant raisonnable facilement accessible pour un usage régulier, et mettez le reste à l’abri.

C’est quoi Electrum ?

Electrum est un wallet bitcoin open source (licence MIT) et multiplateforme (Android, Windows, macOS, Linux) créé par Thomas Voegtlin en novembre 2011. Il est écrit en Python, un langage relativement simple, de plus, son code source est court ce qui le rend facile à auditer. Le projet est toujours très activement maintenu par son créateur et 193 contributeurs.

Ses caractéristiques principales :

  • Wallet protégé : le fichier dans lequel votre clé est enregistrée est chiffré en AES-256-CBC. Un voleur ne peut rien en faire sans le mot de passe.
  • Génération de clé déterministe : si vous perdez votre wallet, vous pouvez le récupérer à partir de sa seed. Vous êtes protégé de vos propres erreurs.
  • Démarrage immédiat : le client ne télécharge pas les 152 Go de la blockchain, il demande cette information à un serveur. Pas de retards, toujours à jour.
  • Transactions signées localement : Vos clés privées ne sont pas partagées avec le serveur. Vous n’avez pas à faire confiance au serveur.
  • Liberté et confidentialité : le serveur ne stocke pas de comptes utilisateurs. Vous n’êtes pas liés à un serveur particulier et il n’a pas besoin de vous connaître. Vous pouvez exporter vos clés privées.
  • Aucun script : Electrum ne télécharge aucun script. Un serveur compromis ne peut pas vous envoyer de code malveillant et voler vos bitcoins.
  • Pas de SPOF (point unique de défaillance) : le code du serveur est open source, n’importe qui peut créer un serveur.
  • Pas de pare-feu à configurer : Le client n’a pas besoin d’ouvrir de port particulier, il interroge simplement le serveur en HTTPS pour les mises à jour.

Mais au fait, t’es qui toi ?

Je m’appelle Blaise Thirard, j’ai 29 ans, je suis entrepreneur et j’ai une formation d’ingénieur système en informatique.

Lorsque j’ai découvert Bitcoin, son cours était d’environ 8 €. Quelques mois plus tard, j’en ai acheté plusieurs, que j’ai rapidement perdus lorsque la plateforme sur laquelle je les avais laissés a brutalement fermé.

J’ai depuis eu l’occasion de méditer sur l’intérêt de ne pas remettre au lendemain la sécurisation de ses cryptos !

On y va ?

Étape 1 : formater la clé USB

Formatez votre clé USB en FAT32 (les données qu’elle contient seront effacées) et laissez-la branchée à votre machine.

Si vous ne savez pas comment formater votre clé USB, je vous invite à suivre ce guide.

Étape 2 : Télécharger UNetbootin

Afin de créer notre clé USB amorçable, téléchargez puis lancez l’application UNetbootin : http://unetbootin.github.io/

UNetbootin est un petit logiciel permettant d’installer un système d’exploitation sur une clé USB. De cette façon, vous pourrez utiliser un autre système sans affecter votre ordinateur (vous retrouverez votre système habituel en retirant la clé USB).

Étape 3 : Créer une clé Ubuntu bootable

Nous allons utiliser la populaire distribution Ubuntu dans sa version 16.04 LTS. Dans les menus déroulants, choisissez Ubuntu et 16.04_Live. Puis, en bas de la fenêtre, ajoutez un espace de 500 Mo et assurez-vous que la lettre du lecteur correspond à votre clé USB, puis cliquez sur OK.

Le téléchargement et l’extraction de la distribution peut prendre un certain temps, mais ils ne nécessitent plus d’intervention de votre part, c’est le bon moment pour aller vous faire un café 😃.

Sous Windows, il peut arriver qu’UNetbootin se fige quelques instants, il retrouvera ses esprits à la fin de la copie des fichiers.

Étape 4 : Booter sur la clé USB

Vous pouvez maintenant redémarrer depuis votre clé USB amorçable. Si vous ne savez pas comment faire, je vous invite à consulter ce guide.

Attention, après avoir démarré sur votre clé USB amorçable, vous n’aurez plus accès à internet jusqu’à l’étape 8. Si vous n’avez pas de smartphone / tablette / ordinateur disponible pour poursuivre la lecture de ce guide pendant cet intervalle, je vous conseille d’imprimer les étapes 5 à 8.

Étape 5 : Démarrer Ubuntu

Dans le menu qui apparaît, sélectionnez la ligne Try Ubuntu without installing grâce aux touches directionnelles de votre clavier, puis validez avec la touche Entrée.

Vous êtes à présent sous Ubuntu !

Ubuntu
Ubuntu

Étape 6 : Configurer le clavier

Si vous utilisez un clavier qwerty, vous pouvez passer à l’étape 7.

Sinon, vous devez configurer Ubuntu pour votre clavier français. Pour cela, dans le coin supérieur droit, cliquez sur l’icône EN. Puis cliquez sur Text Entry Settings...

Ajoutez votre clavier français en cliquant sur le bouton +, puis French, puis Add.

Sélectionnez le clavier anglais puis cliquez sur le bouton - pour le supprimer.

La configuration du clavier est terminée, vous pouvez fermer cette fenêtre en cliquant sur la petite croix rouge en haut à gauche de la fenêtre.

Étape 7 : Configurer le WiFi

Si votre ordinateur est connecté à internet par un câble Ethernet, vous pouvez directement passer à l’étape 8.

Sinon, connectez-vous à votre réseau WiFi en cliquant sur l’icône dans le coin supérieur droit.

Étape 8 : Récupérer le guide

Le menu vertical de gauche permet d’accéder aux logiciels installés. Lancez le navigateur Firefox, puis rouvrez le guide : https://blog.blaisethirard.com/creer-un-cold-storage-un-watching-only-wallet-et-signer-des-transactions-bitcoin-avec-electrum (ne vous ennuyez pas à taper l’adresse entière, les mots clés blog blaise thirard devraient suffire à Google pour vous ramener ici).

Étape 9 : Télécharger Electrum

Nous allons maintenant nous rendre sur le site de l’éditeur d’Electrum afin d’en télécharger la dernière version : https://electrum.org/#download

Dans la section Installation from Python sources, à la ligne Linux, cliquez sur le lien de téléchargement.

Electrum download website

Faites OK pour ouvrir directement le gestionnaire d’archives.

Open Electrum's tar.gz

Cliquez sur Extract pour décompresser Electrum dans votre répertoire personnel.

extract Electrum

Cliquez de nouveau sur Extract puis sur Show the files.

Extract here

Étape 10 : Installer Electrum

Electrum est écrit en Python, un langage de programmation libre, multiplateforme et polyvalent. Nous allons devoir installer les modules Python nécessaires à son fonctionnement. Pour cela, faites clic droit sur le répertoire Electrum-3.0.3, puis Open in Terminal.

Open in Terminal

Copiez-collez les 3 lignes de commande suivantes dans la console puis faites Entrée (pour coller dans la console, faites ctrl + maj + v, ou faites clic droit puis Paste).

sudo add-apt-repository universe &&
sudo apt-get update &&
sudo apt-get install -y python3-setuptools python3-pyqt5 python3-pip dirmngr
  • La première ligne va ajouter le dépôt universe aux sources de logiciels Ubuntu. C’est un dépôt officiel maintenu par la communauté qui contient des paquets libres nécessaires à l’installation d’Electrum.
  • La seconde ligne va mettre à jour la liste des dépôts APT avec le contenu du nouveau dépôt.
  • La troisième ligne va installer les paquets complémentaires nécessaires.

Lorsque l’installation sera terminée, le contenu du terminal arrêtera de défiler et vous récupérerez l’invite de commande.

invite de commande

Electrum est dès à présent en état de fonctionner !

Étape 11 : Désactiver internet

Avant de lancer Electrum, nous allons nous déconnecter d’internet.

Si votre ordinateur est connecté par un câble Ethernet, débranchez-le. Si vous êtes connecté en WiFi, il va également falloir le désactiver. Pour cela, cliquez sur l’icône en haut à droite et décochez Enable Wi-Fi.

Comme c’est important, nous allons nous assurer que votre ordinateur est bien déconnecté d’internet. Pour cela, retournez dans le terminal, et entrez la commande suivante puis faites entrée :

ping -c 3 8.8.8.8

Si vous obtenez le message connect: Network is unreachable, c’est parfait. Sinon, cela signifie que vous êtes toujours connecté à internet, assurez-vous que le câble est correctement débranché et que vous avec bien déconnecté le WiFi.

Is my network disabled ?

Étape 12 : Créer un cold-wallet bitcoin

Nous pouvons enfin lancer Electrum afin de créer notre cold wallet ! Pour cela, dans la console, entrez la commande suivante et faites Entrée :

python3 electrum & sudo gedit /cdrom/pub-key.txt &
  • python3 electrum & : cette commande va lancer Electrum
  • sudo gedit /cdrom/pub-key.txt & : cette commande va lancer un éditeur de texte avec les droits d’écriture nécessaires pour enregistrer le fichier pub-key.txt à l’emplacement /cdrom. Ce fichier nous permettra de sauvegarder la master public key lors de l’étape 13.

Au premier lancement, Electrum va vous demander à quel serveur vous souhaitez vous connecter. Cela ne nous intéresse pas, puisque nous sommes hors ligne. Laissez le choix par défaut et faites Next.

Electrum vous propose de choisir le nom de votre wallet. Nous pouvons laisser le nom par défaut puisque nous ne le conserverons pas.

Electrum propose plusieurs options avancées, nous allons créer un wallet standard.

Nous allons créer une nouvelle seed. La seed est une phrase aléatoire utilisée pour générer la clé privée de notre wallet.


Electrum est probablement le premier wallet à supporter nativement les adresses segwit. Segwit est une mise à jour qui apporte un certain nombre d’améliorations, vous trouverez plus d’informations ici. Malheureusement, en raison de sa jeunesse, la plupart des wallets, brokers et plateformes d’échange ne supportent pas encore ces adresses.

Pour être précis, si vous créez une adresse segwit, vous pourrez recevoir des bitcoins depuis des wallets Electrum (version 3.0 ou supérieure) et en envoyer à tous les wallets, échanges et brokers. Mais vous ne pourrez pas recevoir de bitcoins en provenance de la plupart des autres wallets, échanges et brokers, car ils ne supportent pas encore ce type d’adresses. Pour cette raison, je vous recommande de ne pas créer d’adresse segwit aujourd’hui.

Laissez l’option Standard et cliquez sur Next.

ATTENTION, LISEZ ATTENTIVEMENT CE QUI SUIT !

Le moment est venu de sortir votre papier et votre stylo. Vous devez recopier votre seed  en veillant à ne pas faire de fautes, et à écrire lisiblement.

Faites attention au support sur lequel vous vous appuyez. Évitez les calendriers et les blocs-notes qui laissent des traces. Imprimer votre seed est une mauvaise idée, car les imprimantes peuvent garder en mémoire les derniers documents imprimés. Nous verrons comment sauvegarder votre seed sur le long terme à l’étape 16.

Si vous égarez cette suite de mots, vos bitcoins sont définitivement perdus, il n’existe absolument aucun moyen de récupération.

Lorsque vous avez recopié votre seed, vous pouvez poursuivre en cliquant sur Next.

Vous devez retaper votre seed. Ne faites pas de copier-coller, l’objectif est de s’assurer que vous n’avez fait aucune erreur lorsque vous l’avez notée.

Lorsqu’Electrum génère un wallet, il enregistre votre seed et votre private key dans un fichier sur votre machine, ce qui est dangereux. Pour limiter les risques, nous allons lui demander de chiffrer ce fichier en AES-256-CBC afin de le rendre illisible.

Comme nous avons noté la seed, nous pourrons régénérer notre wallet à volonté, ce fichier nous est donc inutile. Entrez un mot de passe fort, par exemple 4 mots aléatoires, vous n’aurez jamais à vous en souvenir.

Voilà, vous avez sous les yeux votre wallet. Rien ne s’y affiche puisque vous n’avez pas encore fait de transaction et que vous n’êtes pas connecté à internet.

Electrum's interface

Étape 13 : Récupérer la clé publique

Avant d’éteindre l’ordinateur, nous allons récupérer la master public key. Cette clé va nous être utile pour créer notre wallet en lecture seule, c’est-à-dire un wallet dont on peut consulter l’historique des transactions et vers lequel on peut envoyer des bitcoins, mais depuis lequel il est impossible de retirer des bitcoins. Cette clé n’est donc pas sensible comme votre seed, mais vous devez garder à l’esprit que quiconque la possède a la possibilité de consulter l’historique de vos transactions et de savoir combien de bitcoin vous possédez.

Partager cette clé revient à diffuser vos relevés bancaires, à la différence que la sécurité de votre compte bancaire est assurée par une banque. Si vous ne souhaitez pas vous faire braquer comme ce couple d’Anglais, ni enlever comme cet Américain ou ce PDG d’une plateforme d’échange anglaise, je vous recommande ne pas faire étalage du contenu de votre wallet. Même si cela ne représente pas grand-chose aujourd’hui, il se pourrait que sa valeur augmente considérablement demain.

Dans Ubuntu, le menu des applications apparaît dans la barre des tâches lorsque celle-ci est survolée.

Wallet menu

Pour récupérer la master public key, rendez-vous sur Wallet puis cliquez sur Information.

Wallet information

La suite de caractères qui s’affiche est votre master public key, cliquez sur l’icône en bas à droite de la fenêtre pour la copier dans votre presse-papier.

La ligne de commande de l’étape 13 a ouvert Electrum ainsi qu’un éditeur de texte. Retournons dans l’éditeur de texte.

Faites ctrl + v ou clic droit Paste pour coller la master public key, cliquez sur Save, puis cliquez sur la croix rouge en haut à gauche de l’éditeur pour le fermer.

Étape 14 : Effacer ses traces

Il ne nous reste plus qu’à effacer nos traces et éteindre l’ordinateur. Pour cela, nous allons commencer par fermer Electrum. Faites clic droit sur l’icône d’Electrum puis Quit.

Quit Electrum

Ensuite, retournez dans la console, copiez-collez les commandes suivantes et faites Entrée (si vous ne voyez pas la ligne de l’invite de commande, cela signifie que vous n’avez pas fermé Electrum ou l’éditeur de texte).

cd /; sudo su
rm -rf /home/ubuntu/Electrum*
rm -rf /home/ubuntu/.electrum
cat /dev/zero > zero.file
  • La première commande permet de se placer à la racine d’Ubuntu et de prendre les droits administrateur.
  • Les 2 suivantes permettent de supprimer le répertoire qui contient Electrum ainsi que le répertoire dans lequel il a enregistré le fichier chiffré dont nous avons parlé tout à l’heure.
  • Comme vous le savez sans doute, lorsqu’on supprime un fichier, le système d’exploitation se contente de dire que l’espace disque est redevenu disponible, mais il reste présent jusqu’à ce qu’il soit écrasé par un autre fichier. Cette commande permet de créer un fichier que l’on va remplir de zéros jusqu’à ce qu’il n’y ait plus de place disponible sur le support de stockage. De cette façon, nous sommes sûrs que tous les morceaux de fichiers précédemment enregistrés ont été écrasés — sur une clé USB, une seule passe est suffisante, car il n’existe pas de rémanence magnétique résiduelle.

Lorsque vous aurez entré les trois commandes suivantes, votre ordinateur s’éteindra. Vous pourrez débrancher votre clé USB, rebrancher votre câble Ethernet si vous l’aviez débranché, et redémarrer votre ordinateur normalement.

Copiez-collez les commandes suivantes et faites Entrée.

sync
rm zero.file
halt
  • La première commande permet de s’assurer que notre fichier a été correctement écrit sur le support de stockage (il aurait pu rester en mémoire cache).
  • La seconde commande permet de supprimer le fichier rempli de zéros que nous venons de créer.
  • La dernière commande permet d’éteindre l’ordinateur.

Il se peut qu’au lieu de s’éteindre, votre ordinateur reste bloqué sur l’étape de chargement d’Ubuntu, dans ce cas, retirer votre clé USB et restez appuyé 5 secondes sur le bouton d’allumage de votre machine.

Étape 15 : Sauvegarder la clé publique

Vous lisez actuellement ce guide depuis votre ordinateur habituel.

Avant de passer à la suite, vous devez sauvegarder la clé publique que nous avons enregistrée dans le fichier pub-key.txt que nous avons placé à la racine de la clé USB.

Si vous perdez cette public key, ce n’est pas dramatique, car la seed (les 12 mots que vous avez soigneusement recopiés) vous permet de régénérer votre wallet, et donc de la retrouver, mais évitez-vous cette peine, gardez-la !

Nous l’avons vu à l’étape 13, cette clé permet de consulter votre wallet, enregistrez-la à des endroits auxquels vous seul avez accès (email, Dropbox, clé USB bien rangée, téléphone, etc.).

Étape 16 : Sauvegarder la seed Electrum

Faire un wallet super sécurisé c’est bien, à condition de ne pas en perdre l’accès ! Pour cela, il y a deux conditions à considérer :

  1. la pérennité de votre seed
  2. la pérennité d’Electrum

Assurer la pérennité de votre seed Electrum

Comme nous l’avons vu, si vous perdez votre seed, vous perdez vos bitcoins, et c’est irrémédiable. Il est donc important de la mettre en lieux sûrs. “Lieux” est au pluriel, car personne n’est à l’abri d’un incendie ou d’une inondation, vous devez conserver votre sauvegarde dans deux endroits physiquement distincts.

Aussi, afin de limiter les risques, vous ne devez pas écrire votre seed en entier sur vos sauvegardes, scindez-la en deux groupes de 6 mots. De cette façon, si quelqu’un venait à accéder à l’une des moitiés, il ne pourrait rien en faire sans disposer de l’autre.

Ci-dessous, quelques idées à adapter de lieux dans lesquels cacher vos 2 groupes de 6 mots :

  • Le coffre-fort d’une banque (compter environ 100 € par an).
  • Au dos d’une carte de visite, glissée dans un tube d’aspirine (les tubes d’aspirine possèdent un absorbeur d’humidité) que vous rangerez dans un endroit improbable (au fond du congélateur, dans une boite de bâtonnets Croustibat® ? Dans un pot de cactus ? Oui, ça pique, justement :D). Veillez à bien rincer puis sécher l’intérieur du tube (l’aspirine est acide). Non, le placard à pharmacie de la salle de bain n’est pas une bonne cachette, la salle de bain est le premier endroit visité par des cambrioleurs à la recherche d’argent liquide.
  • Sur la tranche supérieure ou inférieure d’une des portes intérieures de la maison (n’allez pas vous faire mal hein !).
  • Un livre de votre bibliothèque (attention le jour où vous faites un vide-grenier !).
  • Un fin morceau de papier glissé derrière l’étiquette d’un flacon de Canard WC®  (l’étiquette des flacons Canard WC® n’est pas collée à la bouteille, il s’agit d’un cerclage en plastique qui a été rétracté thermiquement, il est donc facile d’y glisser quelque chose). Rangez le flacon avec les autres, mais veillez à ne pas l’utiliser afin qu’il ne termine pas à la poubelle…
  • Un poème dans lequel vous utilisez 6 mots de votre seed (attention vous devrez être capable de retrouver les 6 mots utiles dans le bon ordre).
  • Un document quelconque, noyé parmi vos papiers administratifs.
  • Un papier glissé dans une des peluches du petit dernier (je sais, vous n’aviez pas prévu de faire de la couture aujourd’hui…).
  • Un petit bout de papier, glissé dans une de vos dizaines de boules de Noël (certaines se décollent en 2, d’autres sont souples et permettent de faire une légère incision, et pour les rigides, il est parfois possible de décoller le support de l’anneau de fixation afin de faire un petit trou en dessous puis le recoller).
  • Un petit bout de papier, glissé dans le couvercle d’une bombe aérosol d’entretien que vous rangerez sous l’évier, dans le garage, le grenier ou la cave (attention à l’humidité et au ménage de printemps…).
  • Au milieu d’un sachet de pâtes alimentaires qui restera au fond d’un placard (attention aux fringales au retour de soirées arrosées…).

Vous avez séparé votre seed en deux, et vous avez bien caché ces deux groupes de 6 mots. Maintenant, afin de se prémunir d’un dégât matériel important, il faut confier de nouvelles sauvegardes à deux personnes qui ne se connaissent pas (et qui n’habitent pas juste à côté). Je vous laisse leur expliquer pourquoi il faut absolument qu’ils conservent précieusement un flacon de Canard WC®…

Si vous avez le moindre doute sur l’intégrité de votre seed, si quelqu’un en qui vous n’avez pas confiance a eu accès à l’une des moitiés de votre sauvegarde, créez immédiatement un nouveau cold storage, et transférez-y vos bitcoins.

Assurer la pérennité d’Electrum

Electrum est un des wallets Bitcoin les plus populaires, il n’y a donc aucune chance qu’il disparaisse sur le court terme. Cependant, dans plusieurs années, certains événements pourraient compliquer l’accès à vos bitcoins (changement majeur de version, arrêt du support, décès du développeur, etc.).

Je vous conseille de vous renseigner au moins 1 fois par an sur les évolutions d’Electrum. En cas de changement important de version, il vous suffira de créer un nouveau wallet et de transférer vos bitcoins dessus.

Dans ce guide, nous installons Electrum sur la version LTS d’Ubuntu (long term support), cela signifie que son support est assuré jusqu’en avril 2021. Si Electrum venait à disparaître de la surface du web d’ici là (improbable) et que vous en avez conservé les sources, vous pourrez le réinstaller sans le moindre problème.

Vous pouvez récupérer les sources d’Electrum à l’adresse suivante : https://github.com/spesmilo/electrum/archive/master.zip

Créer une version watching-only de votre wallet Electrum

Un watching-only wallet ? Qu’est-ce que c’est ?

Un wallet en lecture seule est un wallet connecté à internet qui vous permet de recevoir des bitcoins, de consulter l’historique complet des transactions qui ont eu lieu sur votre cold storage, mais qui ne peut pas signer de transaction.

Cela rend donc impossible le retrait de bitcoins directement depuis un watching-only wallet. De cette façon, depuis votre téléphone ou votre ordinateur habituel, vous pouvez très simplement alimenter et consulter votre cold storage sans en compromettre la sécurité.

Étape 1 : Installer Electrum

Installer Electrum sur un appareil Android

Vous pourrez installer la version Android officielle d’Electrum directement depuis le Google Play Store en cliquant sur le lien suivant : https://play.google.com/store/apps/details?id=org.electrum.electrum ou en recherchant Electrum Bitcoin Wallet depuis votre appareil Android.

Installer Electrum sur Windows

Pour installer Electrum sur votre ordinateur Windows, rendez-vous sur le site officiel : https://electrum.org/#download

Dans la section Easy installation, cliquez sur Windows Installer puis suivez les étapes habituelles d’installation.

Installer Electrum sur macOS

Pour installer Electrum sur votre Mac, rendez-vous sur le site officiel : https://electrum.org/#download

Dans la section Easy installation, cliquez sur Executable for OS X puis suivez les étapes habituelles d’installation.

Installer Electrum sur Ubuntu, Debian ou Raspbian

Pour installer Electrum sous Linux, rendez-vous sur le site officiel : https://electrum.org/#download

Suivez la procédure décrite dans la section Easy installation.

Si vous rencontrez des difficultés pour installer les dépendances, ajoutez le dépôt universe avec la commande suivante :

add-apt-repository universe && apt-get update

Étape 2 : Créer un watching-only wallet

Lancez Electrum et laissez le choix par défaut puis faites Next.

Electrum vous propose de choisir le nom de votre wallet. Libre à vous de le modifier ou de laisser celui par défaut.

Electrum propose plusieurs options, nous allons rester sur Standard wallet.

Sélectionnez l’option Use public or private keys.

Le moment est venu d’utiliser la master public key de notre cold storage que nous avons sauvegardée tout à l’heure, entrez-la dans le champ texte puis faites Next.

La création de votre watching-only wallet est terminée, Electrum vous affiche le message d’alerte suivant :

Ce wallet est en lecture seule. Cela signifie que vous ne serez pas en mesure de dépenser des bitcoins avec. Assurez-vous de posséder la seed ou les clés privées avant de demander l'envoi de bitcoins vers ce wallet.

C’est une sage recommandation ! Assurez-vous d’avoir mis votre seed en lieux sûrs avant d’envoyer des bitcoins vers votre cold storage.

Présentation de l’interface

Par défaut, Electrum propose trois onglets :

  1. History : affiche l’historique des transactions depuis la création de votre cold storage.
  2. Send : vous permet d’envoyer des bitcoins — cependant, comme votre wallet est en watching-only, la transaction n’aboutira pas, car elle ne sera pas signée. Nous verrons comment signer une transaction depuis votre cold storage dans la section “Signer une transaction, pour retirer des bitcoins de votre cold storage“.
  3. Receive : affiche l’adresse vers laquelle envoyer les bitcoins pour les déposer sur votre cold storage.

En bas à gauche, vous pouvez voir la balance de votre cold storage. Par défaut, celle-ci s’affiche en milliBitcoin. Si vous le souhaitez, vous pouvez changer le préfixe d’unité dans les paramètres, accessibles via l’icône située en bas à droite.

Déposer des bitcoins sur votre cold storage

Pour cela, rien de plus simple, rendez-vous dans l’onglet Receive.

La ligne Receiving address affiche l’adresse à donner à la personne ou à la plateforme depuis laquelle les bitcoins doivent êtres envoyés.

Par mesure de sécurité, cette adresse change à chaque fois qu’elle a été utilisée pour recevoir des bitcoins . Cependant, rien n’empêche d’utiliser une même adresse plusieurs fois.

Lorsque vous envoyez des bitcoins vers votre cold storage, la transaction peut mettre plusieurs minutes à s’afficher et plusieurs heures à être validée.

Si vous n’êtes pas familier avec le transfert de bitcoins , je vous suggère de commencer par ne transférer qu’un petit montant. Cependant, n’oubliez pas que chaque transaction entraîne des frais !

Signer une transaction, pour retirer des bitcoins de votre cold storage

Afin de retirer des bitcoins de votre cold storage, vous devez émettre une transaction signée. Or, comme nous l’avons vu, notre watching only wallet n’est pas capable de signer les transactions.

La procédure à suivre est donc la suivante :

  1. générer une transaction non signée depuis notre watching only wallet connecté,
  2. signer cette transaction hors ligne depuis notre cold storage
  3. diffuser la transaction signée depuis notre watching only wallet connecté.

Étape 1 : Générer une transaction non signée

Depuis votre watching only wallet connecté, rendez-vous dans l’onglet Send.

Dans le champ Pay to, entrez l’adresse vers laquelle vous souhaitez envoyer les bitcoins. Le champ Description est facultatif, il vous permet d’enregistrer des informations supplémentaires sur la transaction ; ces informations ne seront visibles que depuis votre watching only wallet et ne serons pas communiquées au destinataire de la transaction. Le champ Amount vous permet de définir le montant à envoyer, n’oubliez pas que par défaut, l’unité est le milliBitcoin. Comme vous le savez, chaque transaction en bitcoin entraîne des frais, le champ Fee vous permet d’en définir le montant. Notez que plus les frais sont bas, plus la transaction est longue à être exécutée. Si vous ne savez pas quelle valeur mettre, je vous recommande de laisser celle suggérée par Electrum.

Cliquez sur Preview, à la ligne Fee, vérifiez le montant des frais, puis dans la section Outputs, assurez-vous que l’adresse et le montant indiqués sur la ligne surlignée en vert sont corrects et que l’adresse de destination est la bonne (il existe des virus qui changent l’adresse de destination lorsque vous faites un copier-coller). Si tout est bon, cliquez sur Save pour sauvegarder la transaction sur votre ordinateur.

Vous vous demandez peut-être à quoi correspondent les valeurs dans les champs Inputs et Outputs. C’est très simple, je souhaite envoyer 100 mBTC à l’adresse 1PhAJ7RqbVCYqWnayUMTrwTpXhwcJgESbh et cette transaction va me coûter 0.872 mBTC de frais. Comme je n’ai jamais reçu de transaction de ce montant exact, il va falloir en regrouper plusieurs afin que leur somme atteigne au minimum 100.872 mBTC. Ici, une transaction de 54.64 mBTC ainsi qu’une autre de 58.67 mBTC ont été sélectionnées. Je vais envoyer 54.64 + 58.67 = 113.31 mBTC au lieu de 100.872 mBTC. On va donc me rendre la monnaie : 113.31 – 100.872 = 12.438, c’est le montant que vous pouvez voir sur la ligne jaune du champ Outputs.

Étape 2 : Régénérer votre cold wallet pour signer une transaction

Afin de signer votre transaction, vous devez régénérer votre cold wallet à partir de la seed que vous avez précieusement notée quelque part.

Pour cela, suivez les étapes 1 à 3 (comprise) de la section Créer un cold storage avec Electrum. Ensuite, copiez votre transaction non signée à la racine de la clé USB (si vous avez laissé le nom par défaut, le fichier s’appelle unsigned.txn), puis continuez avec les étapes 4 à 11 (comprise).

Dans la console, entrez la commande suivante et faites Entrée pour lancer Electrum :

python3 electrum & sudo gedit /cdrom/signed.txn &

Laissez le choix par défaut et faites Next.

Laissez le nom par défaut et faites Next.

Laissez l’option Standard wallet sélectionnée et faites Next.

Sélectionnez l’option I already have a seed et faites Next.

Entrez les 12 mots qui composent votre seed puis faites Next. Si le bouton Next n’apparaît pas, cela signifie que vous avez fait une faute de frappe.

Entrez un mot de passe fort, par exemple 4 mots aléatoires (vous n’aurez à vous en souvenir que pendant la minute qui suit afin de signer la transaction) et faites Next.

Vous revoilà sur votre cold storage ! Comme vous vous en doutez, aucune information sur son activité ne peut s’afficher, car nous sommes hors ligne.

Cela ne nous empêche pas de pouvoir signer notre transaction. Pour cela, survolez la barre des tâches en haut à gauche afin de faire apparaître le menu d’Electum. Naviguez dans Tools, puis Load transaction et cliquez sur From file.

Il nous faut à présent ouvrir la transaction non signée que nous avons créée depuis notre watching-only wallet et copiée sur notre clé USB. Cliquez sur Computer, puis /, puis cdrom, puis sélectionnez le fichier unsigned.txn, enfin, cliquez sur Open.

Nous retrouvons notre transaction. Au cas où, on vérifie de nouveau que l’adresse de destination (surlignée en vert dans la section Ouputs) ainsi que le montant (sur la même ligne) sont les bons, puis on clique sur le bouton Sign.

Comme notre wallet est chiffré, vous devez entrer le mot de passe que vous avez temporairement créé.

Vous pouvez le constater à la ligne Status, notre transaction est désormais signée. Cliquez sur le bouton Copy situé en bas à gauche de la fenêtre.

Rendez-vous dans l’éditeur de texte qui s’est ouvert en même temps qu’Electrum lorsque nous avons entré la commande dans le terminal, puis faites ctrl + v ou clic droit Paste pour coller la transaction, puis cliquez sur Save.

Voilà, nous en avons terminé avec notre cold storage, je vous invite à présent à fermer Electrum et à effacer vos traces en suivant l’étape 14 de la section Créer un cold storage avec Electrum. Lors de sa fermeture, Electrum va vous informer que la transaction n’est pas enregistrée, ne vous en inquiétez pas, nous l’avons enregistrée directement sur notre clé USB.

Étape 3 : diffuser une transaction signée depuis un watching only wallet

Notre transaction étant signée, il ne nous reste plus qu’à la diffuser. Pour cela, depuis votre système habituel, lancez votre watching-only wallet Electrum.

Dans le menu d’Electum, naviguez dans Tools, puis Load transaction et cliquez sur From file. Naviguez vers la racine de votre clé USB et sélectionnez le fichier signed.txn dans lequel nous venons de sauvegarder la transaction signée, puis cliquez sur Open.

Vous retrouvez la transaction que nous venons de signer depuis notre cold storage. Pour la dernière fois, vérifiez que la transaction que vous venez de charger envoie le bon montant vers la bonne adresse, puis cliquez sur le bouton Broadcast afin de la diffuser.


Si cet article vous a aidé, n’hésitez pas à le partager aux personnes à qui il pourrait être utile. Vous pouvez également me remercier par un don PayPal, ou bitcoin à l’adresse ci-dessous :

1PhAJ7RqbVCYqWnayUMTrwTpXhwcJgESbh

Qu’est-ce que le cloud computing ?

Cloud

Le concept du cloud

Le monde moderne de l’internet et du World Wide Web est composé de centaines de milliers de serveurs répartis dans des milliers de data centers dispersés aux quatre coins du monde. Nous faisons appel à ces serveurs en permanence pour discuter avec d’autres personnes, jouer à des jeux, consulter l’actualité, envoyer des mails, etc. Lorsque depuis notre navigateur nous faisons l’une de ces activités quotidiennes, nous accédons à un programme s’exécutant sur un serveur. Mais où ce programme s’exécute-t-il réellement ? Où sont les données ? Où sont les serveurs ? Ils sont quelque part, là-bas, dans un data center, quelque part dans le monde. Nous ne savons pas où, et plus important encore, nous ne nous en soucions pas ; et il n’y a absolument aucune raison pour que nous nous en inquiétions. Ce qui compte pour nous, c’est que nous pouvons utiliser les logiciels et accéder aux données chaque fois que nous en avons besoin.

C’est l’idée fondamentale du cloud : les programmes et les données sont sur un serveur, quelque part, nous ne savons pas où et cela nous importe peu.

Mais pourquoi appeler cet ensemble de ressources « cloud » ? Un nuage est une immense réserve de minuscules gouttelettes d’eau. Certaines de ces gouttelettes tombent dans nos jardins, apportant de l’eau à nos arbres et nos pelouses ; d’autres s’écoulent et s’infiltrent pour venir emplir les nappes phréatiques à partir desquelles nous puisons notre eau potable. Et les nuages eux-mêmes se développent à partir de l’eau évaporée, qui provient de partout. Tout ce que nous voulons, c’est assez d’eau dans nos jardins pour garder nos plantes en vie et assez d’eau dans nos aquifères pour avoir de l’eau potable. Nous ne nous inquiétons pas de savoir quel nuage va nous apporter la pluie ; cela nous est égal. Nous ne nous inquiétons pas non plus de savoir de quelle partie du globe l’eau provenait ; c’est de l’eau. Les gouttelettes sont toutes les mêmes ; d’ailleurs, ne dit-on pas « se ressembler comme deux gouttes d’eau » ? Tant que nous en avons suffisamment, nous sommes heureux.

Ainsi, nous pouvons faire un parallèle avec cette nuée de data centers répartis sur l’ensemble du globe, tels des nuages. Les plus grands acteurs de l’informatique tels que Google, IBM, Microsoft, Amazon ou Yahoo! possèdent des milliers de machines connectées en réseaux qui exécutent toutes sortes de programmes. Chacun de ces centres est un nuage, et chaque processeur, chaque disque dur est une goutte d’eau dans ce nuage. Dans le monde des nuages, lorsque l’on écrit un programme, nous ne savons pas sur quelle machine il va fonctionner. Nous ne savons pas où les disques qui stockent les données sont, et nous n’avons pas besoin de le savoir. Nous avons juste besoin de savoir de combien de gouttelettes nous avons besoin.

L’évolution du cloud computing

Pour comprendre ce que le cloud computing est et n’est pas, il est important de comprendre comment ce modèle de l’informatique a évolué.

À intervalle régulier, les experts et autres futurologues consacrent une technologie en lui inventant un nom qui deviendra le nouveau buzzword . Ainsi, au cours des dix dernières années, nous avons vu émerger des termes tels que : mobile, WYSIWYG, social, ou encore Web 2.0. Certains ont résisté à l’épreuve du temps, mais pour la plupart, ils sont déjà démodés. Une idée a cependant réussi à traverser les vicissitudes de cet océan de buzzwords : le cloud computing.

Comme l’a fait remarquer Alvin Toffler dans son fameux livre The Third Wave il y a déjà presque 35 ans, la civilisation a progressé par vagues (trois à ce jour : la première fut la vague agraire, la deuxième fut la vague industrielle et la troisième est la vague de la connaissance). Chacune de ces grosses vagues comporte par ailleurs son lot de vaguelettes. Dans cette ère de la connaissance post-industrielle, nous sommes à présent au commencement de ce que certains pressentent être l’ère du cloud computing.

Dans son livre The Big Switch, Nicholas G. Carr compare la révolution de l’information à un changement important ayant eu lieu dans l’ère industrielle. Plus précisément, Carr assimile la montée du cloud computing dans l’ère de l’information à la production et la distribution de l’électricité dans l’ère industrielle. Thomas Edison, l’inventeur de l’ampoule électrique avait son laboratoire à Manhattan et y a créé sa compagnie pour vendre ses ampoules. Cette entreprise, qui plus tard deviendra General Electric, proposait aux propriétaires des grands immeubles de Manhattan d’acheter des générateurs pour produire l’énergie qui leur permettrait d’alimenter en électricité les ampoules installées. Tous les soirs, chaque building mettait donc en marche son générateur. Quelques années plus tard, Samuel Insull, l’un de ses collaborateurs, inventa le grid ; au lieu de faire installer à chacun de ses clients un générateur, des centrales électriques ont été construites sur le territoire. Ainsi, l’installation des éclairages était simplifiée, les entreprises n’avaient plus à fournir leur propre énergie, elles se branchaient simplement sur le grid ; le réseau de distribution électrique était né. Les clients ne savaient plus d’où provenait l’électricité et ne s’en souciaient pas. Nicholas Carr soutient que le cloud computing n’est que le début de la même révolution pour la technologie de l’information.

Actuellement, les entreprises disposent de leurs propres ressources informatiques (générateurs électriques). L’avenir qui se dessine cependant est un futur dans lequel chaque organisation pourra tout simplement se brancher au cloud (le grid) pour ses besoins en ressources informatiques. Car en fin de compte, les économies offertes par les services mutualisés deviendront trop importantes pour être écartées, même pour les plus grandes entreprises.

Comme nous l’avons vu, au sein de chaque vague, il existe de nombreuses vaguelettes, et l’ère de l’information en a déjà connu de nombreuses. Ainsi, nous avons débuté avec les mainframes, et évolué vers les mini-ordinateurs, puis sont venus les ordinateurs personnels, et ainsi de suite ; nous entrons maintenant dans le cloud computing. La figure ci-dessous illustre les vaguelettes de l’ère de l’information :

Les vaguelettes de l'ère de l'information
Les vaguelettes de l’ère de l’information

Au début des années 2000, le PDG d’Oracle a proclamé que l’ensemble des données des utilisateurs serait stocké dans le cloud et que les PC ne seraient guère plus que des terminaux passifs permettant l’accès au web. Bien sûr, la vision de Larry Ellison ne s’est jamais totalement matérialisée, mais certains de ses aspects sont très présents dans nos vies aujourd’hui.

Prenons les mails par exemple, la plupart des utilisateurs possèdent une adresse mail du type Gmail, Hotmail, Yahoo! ou encore La Poste ; ce sont des services de cloud computing. D’autres bons exemples de notre migration vers le cloud sont Google Agenda et Google Docs. Ces deux services stockent nos données dans le cloud pour nous permettre d’y accéder, quel que soit l’ordinateur depuis lequel nous nous connectons au service. Des services tels que DropBox, Google Drive, OneDrive (qui remplace SkyDrive) de Microsoft ou encore hubiC d’OVH nous permettent de stocker et de partager nos fichiers dans le cloud, tandis qu’Office 365 de Microsoft propulse notre suite bureautique dans le cloud.

YouTube, Vimeo et Dailymotion nous permettent de profiter de la vidéo depuis le cloud, tandis que Spotify, Deezer, GrooveShark et autres SoundCloud font de même pour la musique. Google Play Music, iCloud d’Apple et Amazon Cloud Player nous permettent même de stocker nos propres musiques pour les écouter en streaming depuis le cloud partout et tout le temps.

Nous utilisons ainsi au quotidien et souvent sans y prêter attention, de nombreux services hébergés dans le cloud, et ces services facilitent la vie de millions de personnes.
Mais le cloud est loin de n’être réservé qu’aux particuliers. Dans ce Nouveau Monde de l’information, qui requiert une disponibilité permanente, la technologie est devenue la pierre angulaire et joue un rôle critique pour le succès des entreprises. Quelle que soit la taille de l’entreprise, la technologie constitue un avantage économique certain : elle permet d’encourager l’engagement client, d’amplifier la productivité, d’innover et de se différencier de la concurrence. Ainsi, les solutions de cloud computing permettent aux entreprises de réaliser des économies, de simplifier leur structure informatique tout en leur garantissant l’agilité et la flexibilité qui leur est nécessaire pour prospérer.

Le cloud computing défini

La notion de « cloud » a cela de magique que chacun est libre d’y voir ce que bon lui semble. D’ailleurs, comme tout buzzword, il n’avait aucun sens informatique ou scientifique réel et ne s’est imposé que grâce à un matraquage publicitaire. En conséquence, le nuage s’est transformé en brouillard et il était devenu compliqué de savoir de quoi il était question lorsque l’on parlait de cloud. Preuve en est cette étude réalisée en janvier 2009 par Luis M. Vaquero, Luis Rodero-Merino, Juan Caceres et Maik Lindner qui démontre que pas moins de 22 définitions différentes du cloud ont été proposées par des experts.

Par chance, en septembre 2011, le NIST (Institut national des normes et de la technologie) s’en est mêlé et a défini les caractéristiques du cloud computing ; définitions qui ont été depuis largement acceptées.

Côté français, dans son texte n° 42, le Journal officiel n°0129 du 6 juin 2010 page 10453 a émis une définition légale de l’informatique en nuage qui la décrit comme « Mode de traitement des données d’un client, dont l’exploitation s’effectue par l’internet, sous la forme de services fournis par un prestataire. L’informatique en nuage est une forme particulière de gérance de l’informatique, dans laquelle l’emplacement et le fonctionnement du nuage ne sont pas portés à la connaissance des clients. ».

Bien que cette définition soit la seule valable en France juridiquement parlant, elle manque de précision et de spécifications techniques. En conséquence, l’ensemble des caractéristiques et modèles qui seront traités ci-après sont tirés des définitions du cloud computing établies par le NIST dans son document The NIST Definition of Cloud Computing.

Ainsi, pour être qualifiée de cloud, une technologie doit satisfaire aux cinq caractéristiques suivantes :

  • Libre-service à la demande
  • Accès universel
  • Mutualisation des ressources
  • Adaptabilité rapide
  • Paiement à l’usage

Les caractéristiques essentielles du cloud

Le libre-service à la demande

La notion de libre-service à la demande est primordiale pour les utilisateurs de service cloud. Le libre-service à la demande permet à l’utilisateur d’être en mesure de provisionner, mais également de libérer des ressources distantes en temps réel en fonction des besoins, et sans nécessiter d’intervention humaine.

L’accès universel

L’ensemble des ressources doit être accessible et à disposition de l’utilisateur universellement et simplement à travers le réseau, quels que soient les clients utilisés (serveur, PC, client mobile, etc.). Ceci implique trois prédispositions :

  • Accès utilisateur – afin de garantir que l’accès à une solution de cloud soit perçu comme stable et fiable, il est nécessaire que celle-ci dispose d’un accès haut débit
  • Accès applicatif – en vue de s’assurer que la solution soit en mesure de mettre à disposition de l’utilisateur les autres fonctionnalités du cloud, l’accès au réseau doit être disponible au sein même de la solution
  • Accès opérateur – dans le but de pouvoir maintenir et administrer un système cloud correctement, le fournisseur de service cloud doit pouvoir accéder à celui-ci via le réseau

Ainsi, s’assurer qu’un accès total au réseau est disponible dans tous les aspects d’une solution de cloud est essentiel pour offrir l’ensemble des autres caractéristiques.

Mutualisation des ressources

Les ressources matérielles du fournisseur sont partagées entre les différents utilisateurs du service. Ce partage rend l’emplacement exact des données des utilisateurs impossible à déterminer, ce qui peut poser un véritable problème aux entreprises qui sont soumises à de nombreuses contraintes réglementaires concernant la localisation et le contrôle des données. En contrepartie, les économies d’échelle réalisées permettent de réduire les coûts du fournisseur et donc les dépenses des utilisateurs.

Adaptabilité rapide

L’une des caractéristiques du cloud computing est l’élasticité des ressources. Cette caractéristique permet aux utilisateurs de provisionner rapidement de nouvelles ressources de manière à être en mesure de répondre à une montée ou à une descente en charge soudaine. Il n’est jamais évident de prévoir les ressources qui seront nécessaires à la mise en place d’un service informatique quelconque, en particulier lorsque ce besoin est en constante évolution. Le cloud computing offre ainsi un moyen de fournir les ressources informatiques nécessaires à une évolution ou à un pic d’utilisation de ce service.

Paiement à l’usage

Les systèmes cloud doivent être capables de s’autocontrôler et de se gérer pour permettre l’optimisation interne du système. Pour cela, ils s’appuient sur des mesures de référence obtenues grâce à divers mécanismes de supervision. Ces mesures précises permettent une juste facturation des utilisateurs ; ceux-ci ne payeront ainsi que pour les ressources qu’ils ont utilisées et seulement pour la durée qu’ils les ont utilisées.

Les modèles de service

Lorsqu’il est question de cloud computing, il est souvent fait référence aux termes SaaS, PaaS et IaaS. Souvent désignés comme les principales composantes du cloud, ils permettent de déterminer divers degrés d’externalisation. Détaillons.

Software as a Service

Les méthodes traditionnelles de vente de logiciels nécessitaient que le client paye une licence qui lui permettait d’installer et d’utiliser le logiciel sur son propre matériel. Le client avait également la possibilité d’acheter un contrat de maintenance qui lui permettait de recevoir les correctifs pour le logiciel ou d’autres services de support. Le client était préoccupé par la compatibilité des systèmes d’exploitation, l’installation des mises à jour de sécurité ainsi que par les contrats de licence.

Dans le modèle SaaS, le client n’achète pas un logiciel, mais paye un droit d’utilisation. Ce droit d’utilisation peut être facturé grâce à un abonnement, selon l’utilisation du client, ou même gratuitement (souvent avec des fonctionnalités limitées ou une utilisation commerciale des données). En règle générale, le fournisseur délivre un service complet, que ce soit d’un point de vue matériel, logiciel ou support. L’utilisateur accède au service par l’intermédiaire d’une interface web ou d’un périphérique autorisé. Le client n’a ainsi plus à se soucier de la gestion des licences, de l’installation, de la maintenance des machines, des mises à jour logicielles, ni même des recrutements de personnels compétents dans ces domaines.

En termes d’architecture, la différence la plus importante entre le modèle traditionnel et le modèle SaaS est le nombre d’entités que l’application servira. Le modèle traditionnel est un modèle isolé et mono-utilisateur, ce qui signifie qu’un client achète l’application et l’installe sur un serveur. Le serveur n’héberge que cette application spécifique et seul le groupe d’utilisateur du client y a accès. Le modèle SaaS est un modèle multitenant, cela signifie que l’infrastructure matérielle est partagée entre de nombreux clients différents. Cette architecture maximise le partage des ressources matérielles, mais permet tout de même d’être en mesure d’assurer la distinction des données appartenant à chaque client.

Platform as a Service

Dans le modèle PaaS, le fournisseur de service cloud offre un environnement de développement aux développeurs d’applications qui auront également la possibilité de distribuer leurs services à travers la plateforme du fournisseur. Le fournisseur met à disposition des APIs permettant d’instancier une plateforme adaptée aux besoins du client et propose souvent des canaux de distribution et de paiement. Cela permet au client de profiter de canaux de distribution efficaces pour un faible coût d’entrée.

Le Platform as a Service peut être vu comme une variante du Software as a Service dans lequel l’environnement de développement serait proposé en tant que service. Les développeurs utilisent les outils du fournisseur pour créer leurs propres applications, ils peuvent souvent créer des applications web sans avoir à installer le moindre outil sur leur poste de travail. Ensuite, ils ont la possibilité de déployer leurs applications sans pour autant avoir besoin de disposer de compétences en administration système ; cela permet aux développeurs et aux petites entreprises de déployer des applications web sans pour autant devoir supporter la complexité et les coûts engendrés par l’achat et la configuration de serveurs.

En résumé, les solutions de PaaS sont des plateformes de développement pour lesquelles l’outil de développement lui-même est hébergé dans le cloud et accessible via un navigateur. Elles offrent la possibilité aux développeurs de concevoir des applications web sans requérir une expertise spécialisée.

Infrastructure as a Service

Dans le modèle traditionnel des applications hébergées, le vendeur fournit au client toute l’infrastructure nécessaire à l’exécution de ses applications. Souvent, cela implique d’acheter ou de louer des serveurs dédiés à une seule application spécifique.

Le modèle IaaS fournit également l’infrastructure nécessaire à l’exécution des applications, mais l’approche du cloud computing permet d’offrir un modèle du type paiement à l’usage ainsi que la possibilité de redimensionner son instance en fonction du besoin actuel.

Du point de vue du fournisseur d’IaaS, ce modèle lui permet de construire une infrastructure qui gère les pics et les creux de la demande de ses clients et d’ajouter de nouvelles capacités au fur et à mesure que la demande globale augmente. Il facturera ensuite le client pour les ressources qu’il a réellement consommées.

Le client, lui, loue une ressource, il choisit le nombre de cœurs CPU, la quantité de mémoire vive et l’espace disque de cette dernière. Cette instance qu’il loue ne lui appartient pas, savoir comment celle-ci est gérée en interne n’est pas non plus de son ressort, elle est peut-être sur un serveur de dernière génération, ou sur une machine en fin de vie, peut-être a-t-elle même été migrée de serveur en serveur pour finalement changer de data center ? En réalité, la seule chose dont le client veut être certain, c’est qu’il profitera des ressources et de la disponibilité que le fournisseur d’IaaS lui a garanties ; car en fin de compte, toutes ces problématiques techniques, il a choisi de les sous-traiter à un professionnel.

En résumé

Dans le modèle classique, l’utilisation de logiciels d’entreprise classiques nécessite des investissements matériels (coût des locaux, des serveurs, du matériel de sauvegardes, des équipements réseau), logiciels (coût d’achat des licences, coûts annuels de l’assistance, des mises à jour, des changements de versions) et humains conséquents. En contrepartie, l’entreprise garde son indépendance et une totale maitrise de son infrastructure.

Avec le modèle IaaS, le prestataire héberge l’infrastructure informatique de l’utilisateur ou plus généralement de l’entreprise. Cette dernière peut gérer à distance son infrastructure comme si celle-ci se trouvait dans ses propres locaux, les contraintes matérielles en moins. Le prestataire s’occupe ici de la virtualisation, du stockage, des réseaux, du matériel, et de la continuité de service.

Le PaaS désigne de manière générale l’environnement fourni par le prestataire au client. C’est un socle fonctionnel et prêt à l’emploi qui lui est mis à disposition. L’utilisateur aura donc la possibilité de gérer ses applications au sein de celui-ci.

Enfin, le SaaS consiste à fournir des applications hébergées et accessibles en ligne par le biais d’un navigateur web. Les logiciels se présentent sous la forme de services. Une inscription et le paiement d’un droit d’accès permettent généralement à l’utilisateur d’exploiter ces derniers.

La figure suivante illustre les principaux composants de ces quatre modèles, ainsi que les niveaux de responsabilités qui incombent à l’entreprise et au fournisseur de cloud sur chacun des composants.

L’impact du cloud computing sur la structure de gouvernance des organisations informatiques
L’impact du cloud computing sur la structure de gouvernance des organisations informatiques

Les modèles de déploiement

Le terme cloud est une métaphore de l’internet et en est une représentation simplifiée. Le réseau des réseaux, cette galaxie communicante, génère, transmet et reçoit par l’intermédiaire de périphériques interconnectés et de liens entremêlés une constellation de données d’une complexité indescriptible. Les clouds privés et publics en sont des sous-ensembles.

Ces modèles de déploiement, au nombre de quatre, sont définis en fonction de leur relation à l’entreprise.

Cloud public

Dans un cloud public, l’environnement est entièrement détenu par la société qui met à disposition ses services cloud. Les utilisateurs et clients d’un cloud public n’ont de droit ni sur l’infrastructure, ni sur le matériel, ni sur les logiciels, ni sur quoi que ce soit d’autre. Le fournisseur de cloud met à disposition des utilisateurs des ressources. Il conçoit, gère, maintient et fait évoluer ces ressources en fonction des besoins des clients au fil du temps. Dans le domaine du cloud, et du cloud public en particulier, la sécurité est la clé de voute. L’infrastructure étant partagée avec de nombreux clients la sécurité est de la responsabilité du fournisseur qui en assure la gestion. Ce point est d’autant plus crucial que le client n’a qu’un degré de contrôle et de surveillance très faible des aspects physiques et logiques de sécurité sur les ressources qui sont mises à sa disposition. Le fournisseur doit donc tout mettre en œuvre pour garder la confiance de ses utilisateurs.

Modèle de déploiement d'un cloud public
Modèle de déploiement d’un cloud public

Cloud privé

Le terme cloud privé est utilisé pour décrire l’infrastructure qui émule le cloud computing sur un réseau privé. Le cloud privé a pour ambition d’offrir certains avantages du cloud computing tout en en limitant ses inconvénients. Un cloud privé est détenu par l’entreprise utilisatrice, cela nécessite d’acheter, de construire et de maintenir l’ensemble de ses constituants, ce qui implique de supporter un investissement initial très important.

Les clouds privés diffèrent des clouds publics en ce que les réseaux, serveurs, et infrastructures de stockage qui lui sont associés sont dédiés à une seule entreprise et ne sont pas partagés avec d’autres. Puisque le cloud est entièrement contrôlé par l’entreprise elle-même, les risques de sécurité associés à un cloud privé sont minimisés. Ce haut degré de contrôle et de transparence permet au propriétaire d’un cloud privé de se conformer plus facilement à des normes, politiques de sécurités ou conformités réglementaires qui peuvent être requises dans certains domaines.

Modèle de déploiement d'un cloud privé
Modèle de déploiement d’un cloud privé

Cloud communautaire

Le cloud de type communautaire est un modèle de déploiement multitenant partagé entre plusieurs entreprises ou organisations et qui est régi, géré, et sécurisé par l’ensemble des participants ou par un fournisseur de service.

Un cloud communautaire est une forme hybride de cloud privé construit et exploité spécifiquement pour un groupe restreint et ciblé. Ces communautés ont des exigences semblables et réunissent leurs moyens humains et financiers pour atteindre leurs objectifs communs.

L’infrastructure commune est spécifiquement conçue pour répondre aux exigences d’une communauté ; à titre d’exemple, des organismes gouvernementaux, des hôpitaux ou des entreprises de télécommunication qui auraient des contraintes de réseau, de sécurité, de stockage, de calcul ou d’automatisation similaires pourraient trouver des intérêts communs à déployer collectivement un cloud communautaire.

Modèle de déploiement d'un cloud communautaire
Modèle de déploiement d’un cloud communautaire

Cloud hybride

Comme son nom l’indique, un cloud hybride est la combinaison de plusieurs modèles de déploiement de clouds. Avec un cloud hybride, une entreprise peut tirer parti de la simplicité et du faible coût d’un cloud public — pour héberger des services classiques ne requérants pas de précautions particulières — tout en créant son propre cloud privé — pour des applications étroitement intégrées aux systèmes existants ou pour le stockage de données sensibles. Elle a également la possibilité de privilégier l’utilisation de son cloud privé tout en gardant la possibilité de déborder sur une offre de cloud public en cas de besoin temporaire.

Dans un cloud hybride, les clouds public, privé ou communautaire restent des entités uniques, mais sont reliés entre eux par une technologie normalisée ou propriétaire qui permet la portabilité des données et des applications. En raison de la complexité que la combinaison de plusieurs types de clouds engendre, la conception, la gestion et le maintien d’un cloud hybride peuvent être un véritable défi.

Modèle de déploiement d'un cloud hybride
Modèle de déploiement d’un cloud hybride

En résumé

Grâce au cloud computing, de nombreuses ressources peuvent être connectées via des réseaux privés ou publics. Cette technologie simplifie le déploiement d’infrastructures en offrant un support dynamique et évolutif pour héberger des services dont il est souvent compliqué de prévoir l’évolution temporelle.

Les entreprises peuvent choisir de déployer leur infrastructure de cloud en interne, en collaboration avec des partenaires partageant une vision commune, en utilisant les services d’un prestataire de service cloud public, ou bien en alliant plusieurs de ces solutions.

La figure suivante illustre les quatre modèles de déploiement, ainsi que leurs principales caractéristiques.

Les différents types d'environnements de déploiement des services de cloud
Les différents types d’environnements de déploiement des services de cloud

Upgrading OpenStack Havana to Icehouse

openstack-logo
This article describe the way I updated (with Raphaël Walter !) from Havana to OpenStack Icehouse.

We will perform the update service by service in live such a way that we can upgrade the controller independently from the compute nodes, minimizing service disruption.

For each service, the process is as follows:

  • Take down the service
  • Upgrade the packages
  • Upgrade the database
  • Start up the service

All of the below as been tested for an Ubuntu installation.

Let’s go!

Preparing to upgrade OpenStack

First and foremost, we will make backups!

Backup the configuration files

Save the configuration files on all nodes, as shown here:

for service in keystone glance nova cinder openstack-dashboard
do mkdir $service-havana
done

for service in keystone glance nova cinder openstack-dashboard
do cp -r /etc/$service/* $service-havana/
done

Backup databases

Backup all databases on the controller:

mysqldump -u root -p --opt --add-drop-database --all-databases > havana-db-backup.sql

Update systems

On all nodes, we ensure that our systems are up to date:

apt-get update
apt-get upgrade

Update repositories

On all nodes, remove the repository for Havana packages and add the repository for Icehouse packages:

apt-add-repository -r cloud-archive:havana
apt-add-repository cloud-archive:icehouse
apt-get update

Keystone

We stop the keystone service:

service keystone stop

We install some dependencies and the new version of Keystone:

apt-get install python-six python-babel keystone
If you want to know why we need to install the python-six ans python-babel paquets, check in the troubleshooting section.

We upgrade the database schema:

keystone-manage db_sync

We can start the Keystone service:

service keystone start

Glance

We stop the glance and glance-registry services:

service glance-api stop
service glance-registry stop

We install some dependencies and the new version of Glance:

apt-get install python-iso8601 python-keystoneclient python-stevedore glance glance-api

If your tables are not in utf-8, you need to convert them:

mysql -u root -p
mysql> use glance
mysql> ALTER DATABASE glance DEFAULT CHARACTER SET utf8;
mysql> SET FOREIGN_KEY_CHECKS=0;
mysql> ALTER TABLE images CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci; # To do with every tables
mysql> SET FOREIGN_KEY_CHECKS=1;

We upgrade the database schema:

glance-manage db_sync

We can start the Glance service:

service glance start
service glance-registry start

Cinder

We stop the cinder-scheduler, cinder-volume and cinder-api services:

service cinder-scheduler stop
service cinder-volume stop
service cinder-api stop

We install some dependencies and the new version of Cinder:

apt-get install cinder-volume python-cinderclient cinder-scheduler cinder-api

We upgrade the database schema:

cinder-manage db sync

We can start the Cinder services:

service cinder-scheduler start
service cinder-volume start

Nova controller

We stop the nova services:

service nova-consoleauth stop
service nova-novncproxy stop
service nova-cert stop
service nova-conductor stop
service nova-scheduler stop
service nova-api stop

We install some dependencies and the new version of Nova:

apt-get install nova-api nova-cert nova-conductor nova-consoleauth nova-novncproxy nova-scheduler python-novaclient

To enable Icehouse controller services to talk to Havana compute services, we need to set the compute=icehouse-compat option.
Find the [upgrade_levels] section and key in /etc/nova/nova.conf and make sure the version is set to icehouse-compat:

[upgrade_levels]
# Set a version cap for messages sent to compute services. If
# you plan to do a live upgrade from havana to icehouse, you
# should set this option to "icehouse-compat" before beginning
# the live upgrade procedure. (string value)
compute=icehouse-compat

The following configuration options are marked as deprecated in this release. See nova.conf.sample for their replacements. [GROUP]/option :

[DEFAULT]/rabbit_durable_queues
[rpc_notifier2]/topics
[DEFAULT]/log_config
[DEFAULT]/logfile
[DEFAULT]/logdir
[DEFAULT]/base_dir_name
[DEFAULT]/instance_type_extra_specs
[DEFAULT]/db_backend
[DEFAULT]/sql_connection
[DATABASE]/sql_connection
[sql][/sql]/connection
[DEFAULT]/sql_idle_timeout
[DATABASE]/sql_idle_timeout
[sql][/sql]/idle_timeout
[DEFAULT]/sql_min_pool_size
[DATABASE]/sql_min_pool_size
[DEFAULT]/sql_max_pool_size
[DATABASE]/sql_max_pool_size
[DEFAULT]/sql_max_retries
[DATABASE]/sql_max_retries
[DEFAULT]/sql_retry_interval
[DATABASE]/reconnect_interval
[DEFAULT]/sql_max_overflow
[DATABASE]/sqlalchemy_max_overflow
[DEFAULT]/sql_connection_debug
[DEFAULT]/sql_connection_trace
[DATABASE]/sqlalchemy_pool_timeout
[DEFAULT]/memcache_servers
[DEFAULT]/libvirt_type
[DEFAULT]/libvirt_uri
[DEFAULT]/libvirt_inject_password
[DEFAULT]/libvirt_inject_key
[DEFAULT]/libvirt_inject_partition
[DEFAULT]/libvirt_vif_driver
[DEFAULT]/libvirt_volume_drivers
[DEFAULT]/libvirt_disk_prefix
[DEFAULT]/libvirt_wait_soft_reboot_seconds
[DEFAULT]/libvirt_cpu_mode
[DEFAULT]/libvirt_cpu_model
[DEFAULT]/libvirt_snapshots_directory
[DEFAULT]/libvirt_images_type
[DEFAULT]/libvirt_images_volume_group
[DEFAULT]/libvirt_sparse_logical_volumes
[DEFAULT]/libvirt_images_rbd_pool
[DEFAULT]/libvirt_images_rbd_ceph_conf
[DEFAULT]/libvirt_snapshot_compression
[DEFAULT]/libvirt_use_virtio_for_bridges
[DEFAULT]/libvirt_iscsi_use_multipath
[DEFAULT]/libvirt_iser_use_multipath
[DEFAULT]/matchmaker_ringfile
[DEFAULT]/agent_timeout
[DEFAULT]/agent_version_timeout
[DEFAULT]/agent_resetnetwork_timeout
[DEFAULT]/xenapi_agent_path
[DEFAULT]/xenapi_disable_agent
[DEFAULT]/xenapi_use_agent_default
[DEFAULT]/xenapi_login_timeout
[DEFAULT]/xenapi_connection_concurrent
[DEFAULT]/xenapi_connection_url
[DEFAULT]/xenapi_connection_username
[DEFAULT]/xenapi_connection_password
[DEFAULT]/xenapi_vhd_coalesce_poll_interval
[DEFAULT]/xenapi_check_host
[DEFAULT]/xenapi_vhd_coalesce_max_attempts
[DEFAULT]/xenapi_sr_base_path
[DEFAULT]/target_host
[DEFAULT]/target_port
[DEFAULT]/iqn_prefix
[DEFAULT]/xenapi_remap_vbd_dev
[DEFAULT]/xenapi_remap_vbd_dev_prefix
[DEFAULT]/xenapi_torrent_base_url
[DEFAULT]/xenapi_torrent_seed_chance
[DEFAULT]/xenapi_torrent_seed_duration
[DEFAULT]/xenapi_torrent_max_last_accessed
[DEFAULT]/xenapi_torrent_listen_port_start
[DEFAULT]/xenapi_torrent_listen_port_end
[DEFAULT]/xenapi_torrent_download_stall_cutoff
[DEFAULT]/xenapi_torrent_max_seeder_processes_per_host
[DEFAULT]/use_join_force
[DEFAULT]/xenapi_ovs_integration_bridge
[DEFAULT]/cache_images
[DEFAULT]/xenapi_image_compression_level
[DEFAULT]/default_os_type
[DEFAULT]/block_device_creation_timeout
[DEFAULT]/max_kernel_ramdisk_size
[DEFAULT]/sr_matching_filter
[DEFAULT]/xenapi_sparse_copy
[DEFAULT]/xenapi_num_vbd_unplug_retries
[DEFAULT]/xenapi_torrent_images
[DEFAULT]/xenapi_ipxe_network_name
[DEFAULT]/xenapi_ipxe_boot_menu_url
[DEFAULT]/xenapi_ipxe_mkisofs_cmd
[DEFAULT]/xenapi_running_timeout
[DEFAULT]/xenapi_vif_driver
[DEFAULT]/xenapi_image_upload_handler

You need to edit /etc/nova/nova.conf and set the good options. In my case, I have had to replace the logdir option by log_dir:

sed -i -e "s/logdir/log_dir/g" /etc/nova/nova.conf

We upgrade the database schema:

nova-manage db sync

We can start the Nova services:

service nova-consoleauth start
service nova-novncproxy start
service nova-cert start
service nova-conductor start
service nova-scheduler start
service nova-api start

Nova compute

We stop the nova services:

service nova-compute stop
service nova-api-metadata stop
service nova-network stop

We install some dependencies and the new version of Nova:

apt-get install python-six nova-compute-kvm

We upgrade the database schema:

nova-manage db_sync

Because Icehouse brings libguestfs as a requirement. Installing Icehouse dependencies on a system currently running Havana may cause the Havana node to begin using libguestfs and break unexpectedly. It is recommended that libvirt_inject_partition=-2 be set on Havana nodes prior to starting an upgrade of packages on the system.
On the Compute nodes, edit /etc/nova/nova.conf and add:

libvirt_inject_partition=-2

As we have seen, many options are marked as deprecated in this release. See nova.conf.sample for their replacements. You need to edit /etc/nova/nova.conf and set the good options. In my case, I have had to replace the libvirt_cpu_mode, libvirt_cpu_model, libvirt_type, libvirt_use_virtio_for_bridges and logdir options:

sed -i -e "s/libvirt_cpu_mode/cpu_mode/g" /etc/nova/nova.conf
sed -i -e "s/libvirt_cpu_model/cpu_model/g" /etc/nova/nova.conf
sed -i -e "s/libvirt_type/virt_type/g" /etc/nova/nova.conf
sed -i -e "s/libvirt_use_virtio_for_bridges/use_virtio_for_bridges/g" /etc/nova/nova.conf
sed -i -e "s/logdir/log_dir /g" /etc/nova/nova.conf

We can start the Nova services:

service nova-compute start
service nova-api-metadata start
service nova-network start

We must not forget to unset the compute=icehouse-compat option that we set previously.
Find the [upgrade_levels] section and key in /etc/nova/nova.conf and unset icehouse-compat:

[upgrade_levels]
# Set a version cap for messages sent to compute services. If
# you plan to do a live upgrade from havana to icehouse, you
# should set this option to "icehouse-compat" before beginning
# the live upgrade procedure. (string value)
#compute=icehouse-compat

Horizon

There is nothing special to do to upgrade the Horizon service. You only have to upgrade it and restart the Apache HTTP Server:

apt-get install openstack-dashboard
service apache2 restart

OpenStack Icehouse

Troubleshooting

#1

Problem:

root@controller:~/backup-havana/keystone-havana# apt-get install keystone
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
keystone est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 102 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ? O
Paramétrage de keystone (1:2014.1-0ubuntu1~cloud1) ...
Traceback (most recent call last):
  File "/usr/bin/keystone-manage", line 37, in 
    from keystone import cli
  File "/usr/lib/python2.7/dist-packages/keystone/cli.py", line 23, in 
    from keystone.common import sql
  File "/usr/lib/python2.7/dist-packages/keystone/common/sql/__init__.py", line 17, in 
    from keystone.common.sql.core import *
  File "/usr/lib/python2.7/dist-packages/keystone/common/sql/core.py", line 35, in 
    from keystone.openstack.common.db.sqlalchemy import models
  File "/usr/lib/python2.7/dist-packages/keystone/openstack/common/db/sqlalchemy/models.py", line 32, in 
    class ModelBase(six.Iterator):
AttributeError: 'module' object has no attribute 'Iterator'
dpkg : erreur de traitement de keystone (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
 keystone
E: Sub-process /usr/bin/dpkg returned an error code (1)

Solution:

apt-get install python-six

#2

Problem:

2014-04-29 10:52:37.210 22541 ERROR stevedore.extension [-] Could not load 'rabbit': (Babel 0.9.6 (/usr/lib/python2.7/dist-packages), Requirement.parse('Babel>=1.3'))
2014-04-29 10:52:37.210 22541 ERROR stevedore.extension [-] (Babel 0.9.6 (/usr/lib/python2.7/dist-packages), Requirement.parse('Babel>=1.3'))

Solution:

apt-get install python-babel 

#3

Problem:

root@controller:/etc/glance# glance-manage db_sync
2014-04-29 11:01:16.081 23930 CRITICAL glance [-] ValueError: Tables "image_locations,image_members,image_properties,image_tags,images,migrate_version" have non utf8 collation, please make sure all tables are CHARSET=utf8

Solution:
For each tables:

mysql -u root -p
mysql> use glance
mysql> ALTER DATABASE glance DEFAULT CHARACTER SET utf8;
mysql> SET FOREIGN_KEY_CHECKS=0;
mysql> ALTER TABLE images CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

#4

Problem:
In /var/log/glance/registry.log:

2014-04-29 11:00:06.360 23667 TRACE stevedore.extension   File "/usr/lib/python2.7/dist-packages/stevedore/extension.py", line 101, in _load_one_plugin
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension     plugin = ep.load()
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1988, in load
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension     if require: self.require(env, installer)
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2001, in require
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension     working_set.resolve(self.dist.requires(self.extras),env,installer))
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension   File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 588, in resolve
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension     raise VersionConflict(dist,req) # XXX put more info here
2014-04-29 11:00:06.360 23667 TRACE stevedore.extension VersionConflict: (python-keystoneclient 0.3.2 (/usr/lib/python2.7/dist-packages), Requirement.parse('python-keystoneclient>=0.7.0'))

Solution:

apt-get install python-keystoneclient

#5

Problem:

2014-04-29 11:38:38.390 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.428 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.430 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.432 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.437 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.440 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`
2014-04-29 11:38:38.441 26395 WARNING glance.notifier [-] notifier_strategy was deprecated in favor of `notification_driver`

Solution:
In /etc/glance/glance-api.conf:

notification_driver = noop 

Créer des serveurs virtuels Debian 7 Wheezy avec LXC sur un dédié OVH Kimsufi

(Dernière mise à jour : 19 février 2015)

Présentation de LXC

Tout comme Linux-VServer et OpenVZ, LXC est une solution de virtualisation de type isolateur. Cette solution permet la virtualisation par container au niveau du noyau. LXC est très récent et remplace Linux-VServer et OpenVZ. Aussi, LXC est dès à présent intégré au noyau, ce qui n’a jamais été le cas des deux solutions citées précédemment.

L’isolateur tire avantage de la possibilité, unique sous UNIX et Linux, de partager le noyau avec d’autres processus du système. Cette virtualisation à noyau partagé utilise une fonctionnalité nommée chroot. Cette fonctionnalité modifie le système de fichiers racine d’un processus pour l’isoler de manière à fournir une certaine sécurité. On parle alors de « prison » chroot.

Un programme, ensemble de programmes ou système dans le cas de virtualisation à noyau partagé fonctionnant dans un environnement chroot est protégé en faisant croire au système emprisonné qu’il fonctionne sur une machine réelle avec son propre système de fichiers.
Le mécanisme de chroot a été amélioré pour mimer un système de fichiers entier, de sorte qu’un système entier peut fonctionner dans un chroot, ce qui constitue une machine virtuelle.

Cette solution est très performante du fait du peu d’overhead puisque les environnements virtualisés se partagent le code du noyau.

Le schéma ci-dessous représente la technologie de virtualisation par isolation :
Linux Containers

Notes

  • La totalité des opérations décrites ne devrait pas vous prendre plus de 30 minutes (en dehors des temps nécessaires aux compilations qui peut avoisiner 45 minutes en fonction des performances de votre machine)
  • Si une partie d’une ligne de commande est surlignée comme ceci, cela signifie qu’elle peut ou doit être adaptée avec vos paramètres ou préférences
  • Je pars du principe que vous avez déjà installé une distribution sur votre serveur
  • Ce guide a été écrit et testé pour une Debian Wheezy 64 bits, il devrait cependant fonctionner avec ses dérivés (Ubuntu, Xandros, etc.)

Compilation du nouveau noyau Linux

Les noyaux par défaut installés sur les serveurs Kimsufi ont été privés de certaines options malheureusement indispensables au fonctionnement de LXC (Pid namespace, User namespace, Multiple /dev/pts instances, Cgroup namespace, Cgroup sched, Cgroup memory controller, Veth pair device, Macvlan). Pour cette raison, nous allons devoir en compiler un nouveau en activant les options nécessaires.

Avant d’entamer de nombreuses manipulations sur un serveur, j’ai pour habitude de lancer un screen. Cela permet, en cas de coupure de la connexion, de ne pas stopper la tâche en cours (une compilation par exemple) ; vous pourrez donc vous y rattacher et ainsi reprendre là où vous en étiez.

Si screen n’est pas déjà installé :

apt-get install screen

On créé la session screen :

screen -S compil
En cas de déconnexion, vous pourrez reprendre votre session comme ceci :

screen -x compil

Il est même possible de se rattacher à la session depuis plusieurs machines, cela vous permet par exemple de partager votre terminal avec une autre personne qui pourra voir en temps réel ce qu’il s’y passe.

Nous allons commencer par reconfigurer les locales avec le jeu de paramètres régionaux français :

dpkg-reconfigure locales

On décoche les locales suivantes avec la barre d’espace :

  • en_GB ISO-8859-1
  • en_GB.ISO-8859-15 ISO-8859-15
  • en_GB.UTF-8 UTF-8

On coche celles-ci :

  • fr_FR ISO-8859-1
  • fr_FR.UTF-8 UTF-8
  • fr_FR.UTF-8@euro
  • fr_FR@euro ISO-8859-15

On valide, puis dans la fenêtre de dialogue qui suit on sélectionne fr_FR.UTF-8.

Enfin, on précise au système quelle langue utiliser :

echo "LC_ALL=fr_FR.UTF-8" >> /etc/environment
echo "LANG=fr_FR.UTF-8" >> /etc/environment
echo "LANGUAGE=fr_FR.UTF-8" >> /etc/environment

On met à jour le système au cas où :

apt-get update
apt-get upgrade

Pour compiler notre noyau, nous allons avoir besoin d’installer plusieurs outils :

apt-get install make gcc libncurses5-dev lzma dpkg-dev wget

On se créé un répertoire de travail :

mkdir /root/noyau
cd /root/noyau

On récupère la dernière version stable du noyau sur https://www.kernel.org/.

Actuellement la dernière version est la 3.19 :

wget -P /root/noyau -c --no-check-certificate https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.19.tar.xz

On décompresse l’archive et on se place dans le répertoire :

tar -Jxvf linux-3.19.tar.xz
cd /root/noyau/linux-3.19

Par curiosité, on peut regarder quelle est la version du noyau actuellement utilisée :

uname -r

Pour que le noyau que nous allons compiler soit compatible avec la machine, nous allons devoir récupérer la dernière version du fichier de configuration du noyau d’OVH. Ces fichiers sont hébergés ici : ftp://ftp.ovh.net/made-in-ovh/bzImage

On récupère la dernière configuration (actuellement la 3.19.0) :

wget -P /root/noyau/linux-3.19 -c ftp://ftp.ovh.net/made-in-ovh/bzImage/3.19/config-3.19.0-xxxx-std-ipv6-64

Dans l’utilitaire de configuration des options du noyau menuconfig, le nom par défaut du fichier de configuration est « .config », nous allons donc renommer celui que nous venons de télécharger :

mv config-3.19.0-xxxx-std-ipv6-64 .config

On lance l’utilitaire de configuration :

make menuconfig

Si vous n’êtes pas familier avec menuconfig, voici le minimum à savoir :

  • On se déplace avec les flèches haut, bas, gauche et droite
  • On coche une option avec la barre espace ([*] signifie que l’option est activée, [ ] signifie que l’option n’est pas activée)
  • ---> signifie que l’option dispose d’un sous-menu
  • On se rend dans un sous-menu avec la touche entrée

La première étape est de charger le fichier de configuration. Pour cela, on se rend dans <Load> et on valide <Ok> avec la touche entrée.

Ensuite, il faut activer les options suivantes :

General setup --->
    [*] Control Group support --->
        [*] Example debug cgroup subsystem
        [*] Freezer cgroup subsystem
        [*] Device controller for cgroups
        [*] Cpuset support
        [*]  Include legacy /proc/<pid>/cpuset file
        [*] Simple CPU accounting cgroup subsystem
        [*] Resource counters
        [*]  Memory Resource Controller for Control Groups
        [*]   Memory Resource Controller Swap Extension
        [*]    Memory Resource Controller Swap Extension enabled[...]
        [*]   Memory Resource Controller Kernel Memory accountin[...]
        [*] Enable perf_event per-cpu per-container group (cgrou[...]
        [*] Group CPU scheduler --->
            [*] Group scheduling for SCHED_OTHER (NEW)
            [*]  CPU bandwidth provisioning for FAIR_GROUP_SCHED
            [*] Group scheduling for SCHED_RR/FIFO
        [*] Block IO controller
        [*]  Enable Block IO controller debugging
    -*-  Namespaces support --->
        [*] UTS namespace
        [*] IPC namespace
        [*] User namespace
        [*] PID Namespaces
        [*] Network namespace
[*] Enable loadable module support
Networking support --->
    Networking options --->
        <*> 802.1d Ethernet Bridging
        [*]  IGMP/MLD snooping
        [*]  VLAN filtering
        <*> 802.1Q/802.1ad VLAN Support
        [*]  GVRP (GARP VLAN Registration Protocol) support
Device Drivers --->
    [*] Network device support --->
        <*> MAC-VLAN support
        <*>  MAC-VLAN based tap driver
        <*> Virtual ethernet pair device
    Character devices --->
        -*- Unix98 PTY support
        [*]  Support multiple instances of devpts

Une fois la configuration terminée, ne pas oublier d’enregistrer les modifications : <Save> puis <Ok>.

Nous pouvons à présent quitter menuconfig : <Exit> et compiler notre nouveau noyau.

La commande suivante redirige la sortie standard vers le fichier compil.log, cela vous permettra d’en savoir un peu plus en cas de problème ; aussi, pour que la compilation soit plus rapide, vous pouvez adapter l’argument 4 de l’option --jobs en fonction du nombre de threads que peut exécuter votre machine simultanément :

make KDEB_PKGVERSION=3.19.0.cgroups.1.0 deb-pkg --jobs 4 | tee -a compil.log

La compilation devrait durer une bonne demi-heure, voir plus, selon la configuration de votre serveur.

Si tout se passe bien, vous devriez trouver votre nouveau noyau dans /root/noyau : linux-image-3.19.0-xxxx-std-ipv6-64_3.19.0.cgroups.1.0_amd64.deb

LXC repose sur les fonctionnalités des Control Groups qui permettent de limiter, compter, et isoler l’utilisation des ressources processeur, mémoire, ou espace disque ; nous devons donc les monter automatiquement au démarrage de la machine, pour cela, il suffit de les ajouter dans /etc/fstab :

echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab
mkdir -p /sys/fs/cgroup
mount /sys/fs/cgroup

On déplace le noyau actuel :

mv /boot/bzImage-3.14.32-xxxx-grs-ipv6-64 /tmp
mv /boot/System.map-3.14.32-xxxx-grs-ipv6-64 /tmp
mv /etc/grub.d/06_OVHkernel /tmp

Nous pouvons à présent installer le noyau que nous venons de compiler :

dpkg -i /root/noyau/linux-image-3.19.0-xxxx-std-ipv6-64_3.19.0.cgroups.1.0_amd64.deb

Si l’installation s’est bien déroulée, on redémarre le serveur :

reboot

On pense à recréer une session screen :

screen -S compil

On s’assure que nous sommes à présent sur le nouveau noyau :

uname -r

Vous devriez obtenir la valeur suivante : 3.19.0-xxxx-std-ipv6-64

Maintenant que la compilation et l’installation du nouveau noyau Linux sont terminées, nous pouvons passer à l’installation de LXC.

Installation de LXC

LXC est présent dans les dépôts, mais dans une ancienne version, qui de plus, peut poser quelques problèmes. Le projet évoluant assez vite, nous allons récupérer la dernière version directement depuis git et la compiler nous-mêmes.

Pour cela, nous avons besoin de quelques outils :

apt-get install git automake libcap-dev pkg-config docbook2x python3-dev

On récupère le projet complet :

cd /root
git clone https://github.com/lxc/lxc.git

On se place dans le répertoire contenant le projet et on lance le script de génération du makefile :

cd /root/lxc
./autogen.sh

On démarre la compilation en lançant les commandes suivantes une par une :

./configure --enable-doc --enable-python --prefix=/usr | tee -a config.log
make -j4 | tee -a compil.log
make check

On installe LXC :

make install

Un peu de nettoyage :

make distclean

Maintenant que nous avons un noyau compilé spécialement pour l’occasion, et que nous avons installé LXC dans sa version la plus récente, il convient de s’assurer que la configuration du noyau est correcte :

lxc-checkconfig

Tout devrait être à « enable ».

En lançant la commande lxc-checkconfig, vous pouvez voir que le contrôleur memory est activé ce qui n’est pas tout à fait exact ; le terme adéquat serait “supporté” car en réalité, par défaut, il est désactivé. Ce contrôleur permet de limiter l’utilisation de la mémoire (plus d’infos ici et ). Nous allons donc devoir l’activer en remplaçant la ligne GRUB_CMDLINE_LINUX="" du fichier /etc/default/grub par GRUB_CMDLINE_LINUX="cgroup_enable=memory". La commande sed suivante vous épargnera l’édition manuelle du fichier :

sed -i -e "s/GRUB_CMDLINE_LINUX=\"\"/GRUB_CMDLINE_LINUX=\"cgroup_enable=memory\"/g" /etc/default/grub

On applique les modifications puis on redémarre la machine pour la dernière fois :

update-grub
reboot

LXC est à présent prêt à fonctionner, cependant, avant de pouvoir créer des serveurs virtuels, il va nous falloir effectuer une petite modification.

Par défaut, les containers sont stockés dans le répertoire /usr/var/lib/lxc. Or sur un serveur Kimsufi PS 4G de 1To, la partition / ne fait que 20 Go, contre 898 Go pour la partition /home. Nous allons donc déplacer l’emplacement par défaut vers /home/containers.

On créé le répertoire /home/containers :

mkdir /home/containers

On créé un lien symbolique de /usr/var/lib/lxc vers /home/containers :

rm -r /usr/var/lib/lxc
ln -s /home/containers/ /usr/var/lib/lxc

Création d’un serveur virtuel sous Debian Wheezy

On installe les paquets nécessaires à la création du pont et du rootfs :

apt-get install bridge-utils debootstrap

Les templates de création de containers fournis avec LXC sont stockés dans /usr/share/lxc/templates.

Ces templates automatisent l’installation des distributions. Je vous propose de personnaliser le template de création d’un container Debian en modifiant les paramètres de langues et en ajoutant quelques paquets.

On met de côté le template original :

cp /usr/share/lxc/templates/lxc-debian /usr/share/lxc/templates/lxc-debian.bak

De base, les paramètres de langues sont définis en anglais, nous allons éditer deux lignes pour les mettre en français :

  • chroot $rootfs locale-gen en_US.UTF-8 UTF-8 devient chroot $rootfs locale-gen fr_FR.UTF-8
  • chroot $rootfs update-locale LANG=en_US.UTF-8 devient chroot $rootfs update-locale LANG=fr_FR.UTF-8

Les commandes sed suivantes vous épargneront l’édition manuelle du fichier :

sed -i -e "s/locale-gen en_US.UTF-8 UTF-8/locale-gen fr_FR.UTF-8/g" /usr/share/lxc/templates/lxc-debian
sed -i -e "s/update-locale LANG=en_US.UTF-8/update-locale LANG=fr_FR.UTF-8/g" /usr/share/lxc/templates/lxc-debian

Nous allons également ajouter deux paquets : l’éditeur de texte vim et l’utilitaire iputils-ping qui permet de tester l’accessibilité d’une autre machine à travers un réseau IP :
La commande sed suivante vous épargnera l’édition manuelle du fichier :

sed -i -e "s/openssh-server/openssh-server,\\\\\\niputils-ping,\\\\\\nvim/g" /usr/share/lxc/templates/lxc-debian

Nous sommes à présent prêts à créer notre premier container sous Debian Wheezy.
Pour cela rien de plus simple :

  • on créé un nouveau container : lxc-create
  • on lui donne un nom : -n vm1
  • on indique quel template utiliser : -t debian

Ce qui nous donne :

lxc-create -n vm1 -t debian

Comme vous avez pu le constater, l’installation a duré quelques minutes, rassurez-vous, la création de nouveaux containers ne prendra que quelques secondes, car les paquets nécessaires ont été mis en cache.

Nous venons de créer notre premier container, avant de le démarrer, nous allons configurer le réseau pour qu’il ait accès à internet.

Configuration du réseau

Configuration du container

Nous allons commencer par configurer l’interface de notre serveur virtuel en lui attribuant une adresse privée. Pour cela, on édite son fichier interfaces comme suit :

vim /home/containers/vm1/rootfs/etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
		address 192.168.1.2
		netmask 255.255.255.0
		broadcast 192.168.1.255
		gateway 192.168.1.1

Pour finir, on édite le fichier de configuration de notre serveur virtuel en ajoutant les éléments suivants à la fin du fichier :

vim /home/containers/vm1/config
# Network
lxc.utsname = vm1
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.ipv4 = 192.168.1.2/24
lxc.network.ipv4.gateway = 192.168.1.1
lxc.network.veth.pair = veth-vm1

Configuration de l’hôte

Nous allons à présent configurer l’hôte en autorisant le système à rediriger les paquets IP. Pour cela, il suffit d’éditer le fichier /etc/network/interfaces et d’ajouter la ligne suivante pour l’interface eth0 :

vim /etc/network/interfaces
post-up echo 1 > /proc/sys/net/ipv4/ip_forward

Comme nos containers auront chacun une adresse réseau privée, nous allons créer une nouvelle interface qui aura pour rôle de faire un pont entre l’ensemble des adresses privées de nos containers et l’interface physique eth0. Pour cela, on ajoute la configuration suivante à la suite du fichier /etc/network/interfaces :

auto br0
iface br0 inet static
		address 192.168.1.1
		netmask 255.255.255.0
		bridge_ports none
		bridge_stp off
		bridge_fd 0
		bridge_maxwait 5

Pour que l’ensemble de nos containers puisse accéder à internet, nous allons devoir ajouter une règle iptables pour activer le SNAT et la mascarade. Pour cela, on ajoute la ligne suivante pour l’interface eth0 :

post-up iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

Le fichier de configuration du réseau de votre hôte devrait maintenant ressembler à ceci :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
	address 5.39.88.234
	netmask 255.255.255.0
	network 5.39.88.0
	broadcast 5.39.88.255
	gateway 5.39.88.254
	post-up echo 1 > /proc/sys/net/ipv4/ip_forward
	post-up iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

auto br0
iface br0 inet static
	address 192.168.1.1
	netmask 255.255.255.0
	bridge_ports none
	bridge_stp off
	bridge_fd 0
	bridge_maxwait 5

iface eth0 inet6 static
	address 2001:41D0:8:9Aea::1
	netmask 128
	post-up /sbin/ip -f inet6 route add 2001:41D0:8:9Aff:ff:ff:ff:ff dev eth0
	post-up /sbin/ip -f inet6 route add default via 2001:41D0:8:9Aff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del default via 2001:41D0:8:9Aff:ff:ff:ff:ff
	pre-down /sbin/ip -f inet6 route del 2001:41D0:8:9Aff:ff:ff:ff:ff dev eth0

La configuration est à présent terminée, il ne vous reste plus qu’à redémarrer vos interfaces réseau pour enfin profiter des avantages des containers :

service networking restart

Informations utiles

Commandes LXC :

  • Démarrer un container : lxc-start -n vm1
  • Démarrer un container en arrière-plan : lxc-start -n vm1 -d
  • Rentrer dans un container démarré en arrière-plan (pour en sortir faire ctrl+a puis q) : lxc-console -n vm1
  • Arrêter un container (si possible privilégier l’arrêt depuis le container qui est moins brutal): lxc-stop -n vm1
  • Mettre en pause un container : lxc-freeze -n vm1
  • Sortir de pause un container : lxc-unfreeze -n vm1
  • Créer un container : lxc-create -n vm2 -t debian
  • Détruire un container : lxc-destroy -n vm1
  • Afficher la liste des containers : lxc-ls
  • Afficher l’état (démarré/arrêté/en pause) et l’IP de tous les containers : lxc-ls --fancy
  • Afficher des informations sur un container : lxc-info -n vm1
  • Purger le cache d’une image : /usr/share/lxc/templates/lxc-debian --clean

Je vous invite à consulter le manuel pour plus d’informations : man lxc

Quelques règles iptables :

Si vous souhaitez que des services installés sur vos containers soient accessibles depuis l’extérieur, vous devez rediriger les connexions vers les adresses et ports des containers. Pour cela, nous allons utiliser le DNAT.

Si votre container dont l’adresse IP est 192.168.1.2 héberge un serveur HTTP, nous utiliserons la règle suivante pour transférer les connexions entrantes sur le port 80 de l’hôte vers notre container écoutant sur le port 80 :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80

Si vous ne souhaitez pas donner l’accès à internet à l’ensemble de vos containers, mais plutôt au cas par cas, vous pouvez vous inspirer de la règle suivante en lieu et place de celle que nous avons utilisée dans la partie “Configuration de l’hôte” :

iptables -t nat -A POSTROUTING -s 192.168.1.2 -o eth0 -j MASQUERADE

Démarrer des containers automatiquement :

Avec la version 0.8.0-rc1 de LXC, il était possible de démarrer automatiquement des containers lors du démarrage de l’hôte en effectuant un simple lien symbolique : ln -s /var/lib/lxc/vm1/config /etc/lxc/auto/vm1. Mais cette fonctionnalité était en fait offerte par les distributions et non par LXC, cela ne fonctionne donc plus avec la version actuelle.

J’ai pris contact avec le développeur principal de LXC qui m’a dit travailler à l’implémentation de l’auto-start en natif.

En attendant, mon ami Arnaud Valensi a créé un script qui pallie ce manque ; je vous propose de l’utiliser.

On récupère le script dans /etc/inid.d :

wget -P /etc/init.d https://raw.github.com/ArnaudValensi/lxc-ovh/master/files/init.d/lxc

On lui donne les bons droits :

chmod 755 /etc/init.d/lxc

Pour finir, on active le service :

update-rc.d lxc defaults

Pour activer le démarrage automatique d’un container au lancement de l’hôte, il suffira d’écrire la valeur 1 dans un fichier nommé autostart contenu dans le répertoire principal du container :

echo "1" > /home/containers/vm1/autostart

Créez et mémorisez des mots de passe complexes et différents !

Password

De toute façon, je n’ai rien à cacher

Avant de voir comment, voyons pourquoi il est important de ne pas négliger la qualité de ses mots de passe.

Sites de vente en ligne, réseaux sociaux, messageries, banques en ligne ; les services que vous utilisez ont un point commun, ils contiennent de nombreuses informations personnelles vous concernant. Quiconque parviendrait à s’y connecter aurait accès à certaines des informations suivantes :

Historique complet des sites que vous avez visités, des vidéos que vous avez regardées, des personnes que vous avez contactées, des messages que vous avez échangés, des achats que vous avez réalisés, des images que vous avez regardées, vos coordonnées, vos photos, vos vidéos, vos données bancaires, vos informations patrimoniales ou financières, votre localisation géographique actuelle, les activités de vos enfants, vos numéros de permis de conduire, de carte d’identité, d’immatriculation, vos qualités personnelles, vos difficultés sociales, vos problèmes de santé, votre agenda, votre orientation politique, sexuelle ou religieuse ; je m’arrête ici, mais je pense que vous avez saisi l’idée.

Ma question est la suivante : vos mots de passe sont-ils à la hauteur des informations qu’ils protègent ?

Qu’est-ce qu’un bon mot de passe ?

Dans la majorité des ouvrages et des sites spécialisés traitants du sujet, on peut lire qu’un bon mot de passe est avant tout un mot de passe fort, c’est-à-dire difficile à retrouver que ce soit par déduction ou avec des outils automatisés. Ainsi, il ressort que la qualité d’un mot de passe dépend de cinq critères :

  1. sa complexité – les suites de nombres, les dates de naissance, les noms de personnes proches et le nom du chien sont à proscrire
  2. sa longueur – il est admis qu’un mot de passe robuste est composé de 8 à 10 caractères minimum
  3. la diversité des types de caractères – il doit être composé d’un mélange de chiffres, de majuscules, de minuscules et de caractères spéciaux
  4. son exclusivité – un mot de passe doit être unique et ne pas être réutilisé pour plusieurs services
  5. sa durée de vie – idéalement, ce mot de passe devrait être régulièrement modifié, cela, dans l’éventualité où il aurait été découvert

La triste réalité

Force est de constater que ces cinq recommandations ne sont que très rarement mises en application conjointement. Pire, d’après une étude du cabinet Deloitte, les 10 000 mots de passe les plus utilisés suffiraient à accéder à près de 98,1 % des services qu’ils sont censés protéger !

Dans les faits, que constatons-nous aujourd’hui :

  • des mots de passe peu complexes sont utilisés tels que « password », « 123456 », le nom de l’animal de compagnie ou des enfants, les plus téméraires y ajouteront une année de naissance
  • en dehors des chiffres et des lettres, les mots de passe ne contiennent généralement ni majuscules ni caractères spéciaux
  • si une personne possède un mot de passe bien composé (caractères variés et non devinables), celui-ci sera utilisé à l’identique pour l’ensemble des services sur lesquels elle est inscrite
  • un mot de passe long, spécifique à un groupe restreint de services et composé de caractères variés sera noté sur un post-it, dans un carnet ou dans un fichier texte
  • rares sont les personnes qui sont prêtes à changer de mot de passe régulièrement

Pourtant, la plupart de ces personnes sont conscientes des faiblesses de leurs mots de passe. Alors pourquoi ce constat ? La réponse est simple, nous ne sommes pas des machines.

Lorsque nous avons énoncé les cinq critères qui permettaient d’assurer la qualité d’un mot de passe, nous avons omis un sixième critère pourtant essentiel : sa simplicité de mémorisation. En effet, pour des raisons physiologiques, l’être humain ne retient en moyenne que 5 à 7 mots de passe.

Quelle est la solution ?

Le problème étant notre incapacité à retenir de nombreux mots de passe, je vous propose une méthode permettant d’avoir un mot de passe différent pour chaque service sans pour autant avoir à s’en souvenir ou à le noter.

L’idée est d’utiliser un mot de passe dont une partie sera toujours identique et dont l’autre partie dépendra du service utilisé.

Pour cela, je vous propose de conserver votre mot de passe actuel composé du nom et de la date de naissance du fiston, mais d’y apporter quelques modifications.

Votre mot de passe actuel : Laurent89

Pour complexifier ce mot de passe, je vous suggère la technique du décalage. Cette technique – qui ne s’appliquera qu’aux lettres de l’alphabet – consiste à décaler vos doigts d’une touche vers la gauche ou vers la droite de votre clavier. Par exemple, si l’on choisit le décalage vers la droite, la lettre T devient la lettre Y. Cette technique posant problème avec les lettres situées aux extrémités du clavier (les lettres A, Q et W si vous avez choisi le décalage vers la gauche et les lettres P, M et N si vous avez choisi le décalage vers la droite), vous devez choisir un caractère joker. Pour le choix de votre joker, je vous recommande d’utiliser un caractère spécial (quelques exemples : $ * . / + – ? !).

Pour l’exemple, je vais choisir le décalage vers la droite et le joker suivant : $. Notre mot de passe devient donc : Mzitr$y89

Nous avons notre mot de passe de base, il ne nous reste plus qu’à lui ajouter un préfixe (ou un suffixe !) qui dépendra du service sur lequel vous vous identifiez. L’idée est bien sûr de ne pas avoir besoin de faire travailler sa mémoire pour retrouver ce suffixe. Je vous propose d’utiliser les 3 premiers caractères du nom du service. Par exemple, pour facebook.com, vous garderez « fac », pour Google « goo », pour votre compte Skype « sky », etc.

Pour l’exemple, nous allons générer un mot de passe pour nous connecter à notre compte Google. Nous ajoutons donc le préfixe « goo » à notre mot de passe, et bien sûr nous lui appliquons le décalage, cela nous donne : hppMzitr$y89

Mot de passe généré avec la technique du décalage

Et le critère numéro 5 ?

Le critère numéro 5 de qualité d’un mot de passe est sa durée de vie, qui idéalement, dans le cas d’un service critique, devrait être limitée à un mois. Malheureusement, lorsque l’on est inscrit sur des dizaines, voire des centaines de sites, il est très contraignant de changer ses mots de passe régulièrement et cela nécessite une vraie organisation. Il est d’ailleurs peu probable que vous vous donniez cette peine ; d’autant plus qu’il y a de fortes chances pour que vous ne fréquentiez pas mensuellement certains des sites sur lesquels vous êtes inscrits. Je vous recommande tout de même fortement de renouveler la totalité de vos mots de passe à minima chaque année.

La première idée venant à l’esprit lorsque l’on souhaite générer un mot de passe dont la durée de vie est limitée dans le temps est d’ajouter la date au mot de passe. Par exemple, à la place de l’année de naissance, nous pourrions ajouter l’année actuelle : hppMzitr$y13.

Mais ici, la problématique est double, il faut d’une part être capable de se souvenir d’un mot de passe qui aurait été généré de nombreuses années auparavant, mais aussi empêcher une personne qui aurait récupéré plusieurs de vos mots de passe de retrouver la méthode qui a permis de les générer.
Pour cela, nous allons utiliser une calculatrice et un nombre décimal de votre choix. Il est primordial de choisir un nombre décimal dont vous vous souviendrez sur le long terme, quelques exemples :

  • π : 3.1415
  • euro/franc : 6.55957
  • date de naissance : 1.8031988 (18 mars 1988)
  • code postal : 1.3200

Nous multiplierons ce nombre par l’année et en garderons les 3 premières décimales. Par exemple, si nous choisissons le nombre 3.1415 nous avons :

  • pour l’année 2013 : 3.1415 x 13 = 40.8395
  • pour l’année 2014 : 3.1415 x 14 = 43.981
  • pour l’année 2015 : 3.1415 x 15 = 47.1225

Selon le nombre décimal que vous utilisez, il peut arriver que le résultat du calcul ne vous donne qu’une ou deux décimales, il suffira dans ce cas-là d’ajouter votre joker au résultat pour obtenir les 3 décimales nécessaires.

Pour l’année 2013, notre mot de passe Google sera donc : hppMzitr$y839

Pour conclure

Nous venons de répondre aux questions suivantes :

  • Pourquoi le choix d’un bon mot de passe est-il important ?
  • Qu’est-ce qu’un bon mot de passe ?
  • Pourquoi les recommandations de création d’un bon mot de passe ne sont-elles pas mieux respectées ?
  • Comment créer et retenir des mots de passe correctement construits ?

La méthode que je vous ai présentée n’est qu’une façon de faire parmi bien d’autres, mon but ici était de vous donner une base simple à comprendre et facilement utilisable ; libre à vous de la modifier et de l’adapter selon vos besoins et vos préférences. Vous pouvez par exemple décaler les voyelles vers la gauche et les consonnes vers la droite, utiliser un décalage de deux touches, inverser l’ordre des préfixes/suffixes (« cba » au lieu de « abc »), utiliser une suite de plusieurs jokers, etc.

Enfin, pensez à utiliser les moyens de sécurisation supplémentaires que certains sites mettent à votre disposition. Par exemple, Google, Facebook, Twitter, OVH et bien d’autres proposent la double authentification dont le principe est de demander en plus du mot de passe un code, envoyé par SMS.

J’espère que cet article vous aura été utile, n’hésitez pas à partager vos astuces et remarques.

Créer une seedbox avec qBittorrent sous Debian Wheezy

(Dernière mise à jour : 12 mai 2014)

Présentation de qBittorrent

qBittorrent est un client bittorrent très léger développé en C++ avec la bibliothèque Qt4. Il est libre, multiplateforme et dispose d’une interface web en Ajax, il peut donc fonctionner sans serveur X. Nous allons voir comment l’installer en ligne de commande sur un serveur ne disposant pas d’interface graphique.
Ce guide fonctionne pour Debian, Ubuntu et ses dérivés.

qBittorrent
Capture d’écran de l’interface web de qBittorrent

Installation des dépendances

La compilation de qBittorrent nécessite l’installation de plusieurs dépendances.

On installe les outils de base :

apt-get install build-essential libtool automake autoconf subversion git wget pkg-config python

Les librairies SSL et Boost :

apt-get install libboost-date-time-dev libboost-dev libboost-filesystem-dev \
libboost-iostreams-dev libboost-program-options-dev libboost-regex-dev \
libboost-serialization-dev libboost-signals-dev libboost-test-dev \
libboost-thread-dev libssl-dev

La librairie Qt4 :

apt-get install libqt4-dev

Compilation de Libtorrent

qBittorrent utilise la librairie libtorrent, il est donc nécessaire de la compiler et de l’installer avant de pouvoir faire de même avec qBittorrent.

Nous allons donc commencer par récupérer la dernière version de la librairie depuis le svn :

mkdir -p qBittorrent_compiling
cd qBittorrent_compiling
svn co https://svn.code.sf.net/p/libtorrent/code/branches/RC_0_16 libtorrent

Vous devriez à présent disposer de la dernière branche svn de libtorrent dans le répertoire du même nom. Comme le fichier de configuration n’est pas fourni, nous allons le créer nous-mêmes :

cd libtorrent
./autotool.sh

Nous pouvons à présent compiler la librairie :

./configure --disable-debug --prefix=/usr && make clean && make

Il ne nous reste plus qu’à l’installer :

make uninstall
make install-strip

Compilation de qBittorrent

On récupère la dernière version de qBittorrent depuis git :

cd ..
git clone https://github.com/qbittorrent/qBittorrent.git

On la compile en désactivant l’interface graphique :

cd qBittorrent
./configure --prefix=/usr --disable-gui
make

On installe qBittorrent :

make install

Lancer qBittorrent au démarrage du serveur

Donner les droits root à une application de ce type étant une très mauvaise idée, nous allons créer un utilisateur spécifique :

adduser qbittorrent

Un utilisateur de qBittorrent (Jesper Smith) a créé un script d’initialisation. Nous allons donc le récupérer :

wget -P /etc/init.d http://blaisethirard.fr/partage/blog/qbittorrent-nox-daemon

(Si vous n’avez pas nommé le nouvel utilisateur “qbittorrent”, pensez à remplacer “qbittorrent” à la ligne 25 du script /etc/init.d/qbittorrent-nox-daemon par le nom de l’utilisateur que vous avez créé.)

On lui donne les bons droits :

chmod 755 /etc/init.d/qbittorrent-nox-daemon

On exécute le script d’initialisation au démarrage du système :

update-rc.d qbittorrent-nox-daemon defaults

Au premier démarrage de qBittorrent, un message d’avertissement s’affiche et vous demande de taper “y” afin de pouvoir continuer. Pour cette raison, nous allons nous connecter avec l’utilisateur qbittorrent et lancer le programme manuellement :

su qbittorrent
qbittorrent-nox
******** Informations ********
 Pour contrôler qBittorrent, accéder à l'interface Web via http://localhost:8080
 Le nom d'utilisateur de l'administrateur de l'interface Web est : admin
 Le mot de passe de l'administrateur de l'interface Web est toujours celui par défaut : adminadmin
 Ceci peut être dangereux, veuillez penser à changer votre mot de passe dans les options.
 15/09/2013 04:59:57 - L'interface Web est associée au port 8080

Au prochain démarrage de votre serveur, le service qbittorrent-nox sera automatiquement lancé en arrière-plan.

Un peu de ménage :

rm -r ~/qBittorrent_compiling

L’installation est terminée, pensez à changer l’utilisateur et le mot de passe par défaut de qBittorent : Outils > Options… > Interface Web > Authentification

Installation de Linux-VServer sur Debian GNU/Linux 7.0 (Wheezy)

Comme vous le savez sans doute si vous n’êtes pas tombé sur cet article par hasard, avec cette dernière version de Debian, Linux-VServer devient obsolète. Cela signifie qu’il va bientôt falloir migrer vers une autre solution de virtualisation (KVM, Linux Container ou Xen). Cependant, vous avez peut-être besoin de poursuivre avec Linux-VServer quelque temps sans pour autant vous priver de la dernière version stable de Debian.
Si vous êtes conscients que le projet Debian arrête le suivi en sécurité de Linux-VServer et qu’il n’y aura plus de support de ce composant, suivez le guide. Sinon, je vous invite à passer à LXC.

Notes :

  • Je pars du principe que vous avez déjà installé Debian Wheezy
  • Si une partie d’une ligne de commande est surlignée comme ceci, cela signifie qu’elle peut ou doit être adaptée avec vos paramètres ou préférences
  • Ce guide est conçu pour que dans la plupart des cas, vous puissiez vous contenter de faire des copier / coller

Dans le fichier /etc/apt/sources.list, on commente la ligne relative au cd-rom :

sed -i "s/^\(deb cdrom.*\)/#\1$/g" /etc/apt/sources.list

On met à jour le système :

apt-get update
apt-get upgrade

On installe les outils de base et ceux qui seront nécessaires à la compilation :

apt-get install \
wget \
build-essential \
kernel-package \
initramfs-tools \
module-init-tools \
libncurses5-dev \
e2fslibs-dev \
dietlibc-dev \
pkg-config \
vlan \
libnss3 \
libnss3-dev \
debootstrap

On récupère la dernière version du patch Linux-VServer depuis le site http://vserver.13thfloor.at/Experimental/ :

wget -P /usr/src http://vserver.13thfloor.at/Experimental/patch-3.9.5-vs2.3.6.5.diff

On récupère le kernel correspondant depuis le site https://www.kernel.org/pub/linux/kernel/ ou https://www.kernel.org/ :

wget -P /usr/src https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.9.5.tar.gz

On se place dans /etc/src et on décompresse le kernel :

cd /usr/src
tar xvfz linux-3.9.5.tar.gz

On créé le lien symbolique /usr/src/linux qui pointe vers les sources du noyau :

ln -s linux-3.9.5 linux

On récupère la configuration du noyau actuellement en service puis on la copie dans celle du nouveau noyau :

cp /boot/config-3.2.0-4-686-pae /usr/src/linux/.config

Il est également possible de récupérer cette configuration dans le système de fichier procfs, si l’optionKernel .config support du noyau était activée pour le noyau en service :

zcat /proc/config.gz > /usr/src/linux/.config

ou encore dans le répertoire kernel du noyau actuellement en service :

cp /usr/src/linux-3.9.5/.config /usr/src/linux/

On se place dans /usr/src/linux et on applique le patch :

cd /usr/src/linux
patch -p1 < ../patch-3.9.5-vs2.3.6.5.diff

On lance menuconfig :

make menuconfig

et on active les options suivantes :

  • « Enable loadable module support »
  • « Linux VServer »
    • « Automatically Assign Loopback IP »
    • « Enable COW Immutable Link Breaking »
    • « Enable Proc Security »
    • « VServer Warnings »
    • « VServer DevPTS Warnings »

Pensez à enregistrer vos modifications avant de quitter menuconfig : < Save >

On efface tous les fichiers créés dans le répertoire des sources du noyau par la cible build :

make-kpkg clean

On lance la compilation du kernel (l’argument « 4 » de l’option « --jobs » est à adapter en fonction du nombre de threads que peut exécuter votre machine simultanément) :

make-kpkg --initrd --append-to-version vserver --revision 1 kernel-image --jobs 4

Si la compilation s’est bien déroulée, un paquet .deb a été créé dans /usr/src.
On installe le nouveau kernel :

dpkg -i /usr/src/linux-image-3.9.5-vs2.3.6.5vserver_1_amd64.deb

Si vous êtes sur une machine distante à laquelle vous n’avez pas d’accès physique, je vous recommande très fortement de prendre la précaution détaillée dans mon article précédent avant de redémarrer la machine : https://blog.blaisethirard.com/grub-precaution-a-prendre-apres-la-compilation-d-un-nouveau-kernel-sur-un-serveur-distant/

On redémarre la machine :

reboot

Une fois la machine redémarrée, on vérifie que le noyau utilisé est bien celui que nous venons d’installer :

uname -r

Maintenant que nous sommes sur le noyau patché, il ne nous reste plus qu’à installer util-vserver. Pour cela, on télécharge la dernière version à cette adresse : http://people.linux-vserver.org/~dhozac/t/uv-testing :

wget -P /usr/src http://people.linux-vserver.org/~dhozac/t/uv-testing/util-vserver-0.30.216-pre3038.tar.bz2

On se place dans /etc/src et on décompresse l’archive :

cd /usr/src
tar jxvf util-vserver-0.30.216-pre3038.tar.bz2

On se place dans /etc/src/util-vserver-0.30.216-pre3038/ et on lance le script de configuration :

cd util-vserver-0.30.216-pre3038/
./configure --prefix=/usr --enable-release --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc --enable-dietlibc --localstatedir=/var --with-vrootdir=/home/srv

On compile util-vserver :

make
make install
make install-distribution

Le script vshelper est utilisé pour arrêter et redémarrer correctement les serveurs virtuels. Nous allons donc indiquer au noyau où il se trouve :

echo /usr/lib/util-vserver/vshelper >| /proc/sys/kernel/vshelper
echo kernel.vshelper = /usr/lib/util-vserver/vshelper >> /etc/sysctl.conf

On démarre util-vserver :

service util-vserver start

Pour finir, on configure le démarrage automatique des services :

update-rc.d vprocunhide defaults
update-rc.d util-vserver defaults
update-rc.d vservers-default defaults

Linux-VServer est à présent installé et fonctionnel sur votre Debian Wheezy !

Grub : la précaution à prendre après la compilation d’un nouveau kernel sur un serveur distant

Si vous intervenez sur un serveur distant et que vous devez compiler ou installer un nouveau noyau, il est prudent de prendre ses précautions et de configurer Grub pour qu’en cas de kernel panic, il ne reste pas bloqué sur la séquence de démarrage du noyau…

Il est possible de configurer Grub pour qu’il démarre sur le nouveau kernel et qu’en cas de problème, il redémarre automatiquement sur l’ancien kernel fonctionnel.

Ce guide concerne la version 2 de Grub et a été testé sous Debian, il devrait également fonctionner pour ses dérivés (Ubuntu, Xandros, etc.). Vous pouvez vérifier votre version de Grub avec la commande suivante :

grub-install -v

Si la commande retourne « GNU GRUB 1.98 » ou plus, vous utilisez Grub 2, si elle retourne « 0.97 », vous utilisez Grub Legacy.

Une fois que votre nouveau noyau est compilé et installé, il faut éditer le fichier /etc/default/grub et le configurer comme suit.

On ajoute l’option « panic=5 » à la ligne « GRUB_CMDLINE_LINUX_DEFAULT » pour redémarrer le kernel au bout de 5 secondes s’il y a un problème lors du démarrage :

GRUB_CMDLINE_LINUX_DEFAULT="quiet panic=5"

On remplace « GRUB_DEFAULT=0 » par « GRUB_DEFAULT=saved ». Cela permet à Grub de ne démarrer sur le nouveau kernel qu’une seule fois. En cas de kernel panic, la machine pourra redémarrer sur l’ancien noyau :

GRUB_DEFAULT=saved

Lorsque les deux modifications du fichier /etc/default/grub on été effectuées et sauvegardées, on récupère le nom du kernel actuel (celui dont on est sûr du bon fonctionnement) et de celui que l’on vient de compiler :

cat /boot/grub/grub.cfg
--> Debian GNU/Linux, avec Linux 3.2.0-4-amd64
--> Debian GNU/Linux, avec Linux 3.9.5-vs2.3.6.5revised-kernel

On définit l’ancien kernel par défaut :

grub-set-default "Debian GNU/Linux, avec Linux 3.2.0-4-amd64"

On configure Grub pour qu’il redémarre une fois sur le nouveau kernel :

grub-reboot "Debian GNU/Linux, avec Linux 3.9.5-vs2.3.6.5revised-kernel"

On régénère le fichier /boot/grub/grub.cfg :

update-grub

On redémarre le serveur :

reboot

On vérifie que la machine a bien redémarré sur son nouveau noyau :

uname -r

Si tout est bon, on définit le nouveau noyau par défaut :

grub-set-default "Debian GNU/Linux, avec Linux 3.9.5-vs2.3.6.5revised-kernel"