Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : auto-hébergement

Sortie officielle de Dotclear 2.13

Matthieu Saulnier

La Devteam du CMS Dotclear vient de dévoiler le cru 2018. La version 2.13 est une importante version, elle contient toutes les modifications de la version 2.12.2 en plus des nouvelles features de la 2.13.

Ce modeste weblog tourne lui-même en ce moment sur la 2.13

On va pas se voiler la face, depuis 2012 j'ai testé beaucoup de moteurs de blog : Hugo, Pelican, Mezzanine, Wordpress... Seul Dotclear est resté. Il faut avouer qu'il fait le job avec excellence. Il est le seul à fournir une interface admin complète mais pas compliquée. Aucune faille de sécurité, des perfs à faire chavirer, bref, Dotclear représente pour moi une valeur sûre pour les années à venir.

Et si cette version se révélait être un très bon cru

Il y a une fonctionnalité que j'attendais avec impatience! Pour vous situer le contexte, j'avais posé une question toute bête à la Devteam il y a quelques temps déjà, l'issue de la discussion était un fix prévu dans cette version.

Capture décran_2017-12-30_10-12-55.png

Il est beau le Changelog, pas vrai? Et donc la fonctionnalité que j'attendais sous le sapin est : « Cope with MySQLi connection via socket ». Je prévois d'écrire un petit article sur le sujet.

Du fun

Cette version s'annonce très prometteuse, c'est moi qui vous le dit...

Sortie officielle de Dotclear 2.13

Matthieu Saulnier

La Devteam du CMS Dotclear vient de dévoiler le cru 2018. La version 2.13 est une importante version, elle contient toutes les modifications de la version 2.12.2 en plus des nouvelles features de la 2.13.

Ce modeste weblog tourne lui-même en ce moment sur la 2.13

On va pas se voiler la face, depuis 2012 j'ai testé beaucoup de moteurs de blog : Hugo, Pelican, Mezzanine, Wordpress... Seul Dotclear est resté. Il faut avouer qu'il fait le job avec excellence. Il est le seul à fournir une interface admin complète mais pas compliquée. Aucune faille de sécurité, des perfs à faire chavirer, bref, Dotclear représente pour moi une valeur sûre pour les années à venir.

Et si cette version se révélait être un très bon cru

Il y a une fonctionnalité que j'attendais avec impatience! Pour vous situer le contexte, j'avais posé une question toute bête à la Devteam il y a quelques temps déjà, l'issue de la discussion était un fix prévu dans cette version.

Capture décran_2017-12-30_10-12-55.png

Il est beau le Changelog, pas vrai? Et donc la fonctionnalité que j'attendais sous le sapin est : « Cope with MySQLi connection via socket ». Je prévois d'écrire un petit article sur le sujet.

Du fun

Cette version s'annonce très prometteuse, c'est moi qui vous le dit...

Da FAI

Matthieu Saulnier

Pour ceux qui ont des freebox, j'ai trouvé un petit tour rigolo. Si vous êtes comme moi et que vous voulez faire à l'occasion (petites coupures, autres...) des diagnostics rapides de l'ensemble de tous les composants réseau, afficher l'uptime de la freebox dans un terminal en une seule commande va être assurément intéressant.

Vous connaissez sans doute l'adresse pour afficher le rapport complet :

http://mafreebox.free.fr/pub/fbx_info.txt

Donc on peut déjà afficher le rapport complet dans un terminal :

casper@falcon ~ % export FBX=http://mafreebox.free.fr/pub/fbx_info.txt
casper@falcon ~ % curl $FBX

C'est un début mais ça floode encore pas mal le terminal, on peut faire mieux...

casper@falcon ~ % curl $FBX 2>/dev/null | grep "mise en route" | cut -d " " -f10,11,12,13
4 heures, 33 minutes

Bon, j'ai rien inventé, mais j'espère que cette astuce vous sera utile un jour. N'hésitez pas à mettre un pouce vert, un com', tout ce que vous voulez, et surtout de vous abonner pour être automatiquement averti de la sortie d'une nouvelle vidéo !

Persistence des données

Matthieu Saulnier

Salut lecteur,

Oui toi, pas la peine de regarder à gauche ou à droite, il y a absolument personne, je parle bien à toi cher lecteur. Tu as cru que je t'avais oublié, pas vrai ? Du tout, mais comme tu le sais, j'ai eu pas mal de distractions ces derniers temps, j'ai vraiment du mal à trouver du temps pour t'écrire.

En plus, faut vraiment être motivé pour lire un article de plus sur Docker. Oui Docker, au travail j'ai carrément augmenté mon skill à ce sujet, et j'ai grave envie de t'en parler mon lecteur. D'ailleurs si t'as envie de connaitre mon opinion sur ce « truc », Aeris l'exprime parfaitement sur son blog, dans un article purement philosophique comme je les aime.

Au début je m'étais dit exactement comme tout le monde : AWESOME FAUT QUE JE DOCKERISE TOUS MES SERVEURS!!!! et puis je suis redescendu sur terre. Pour donner une proportion, j'en suis à 30% de mes services en container Docker, et ça n'augmentera plus. Pour illustrer pourquoi, je vais juste dire que mes serveurs imap et smtp utilisent les utilisateurs système de l'hôte, et ils doivent rester en correllation avec les utilisateurs SSH. C'est d'ailleurs la définition d'un « système », en fait. Pour le reste, soit.

Et puis vient la question de mettre quoi en container, de cloisonner quoi exactement. Dans un précédent article, je mettais tout en container, vraiment tout, et c'est vraiment pas pratique.

En fait, il m'a fallu un peu de temps avant de maitriser complètement la ligne de commande Docker, je parle de comprendre tous les concepts qu'elle induit, pour au final ne retenir qu'une seule philosophie. C'est le problème typique qu'on rencontre quand un système propose trop de possibilités. Avais-tu remarqué dans l'article précédent que je mettais les données statiques à disposition à travers un container statique ? Que se passerait-t-il si ce container disparaissait ?

Comme la plupart des gens qui font une utilisation intensive du service Docker, j'ai eu à un moment, tôt ou tard, besoin de supprimer /var/lib/docker pour résoudre un gros problème : Le service Docker ne démarrait plus. Inutile de te dire que le container disparait comme par magie, et que j'ai eu très peur pour mes données. Mais, je suis un hébergeur sérieux... j'ai des backups journaliers ^^

Cette mésaventure m'a poussé à repenser mes possiblités avec le service, cette fois-ci en considérant les containers comme non-définitifs. S'ils ne sont plus définitifs, alors ils ne doivent plus démarrer automatiquement au démarrage de l'hôte (virer l'option --restart always), et la "démonification" (option -d) doit être gérée par un gestionnaire de services, prenons Systemd.

Avec systemd, on pourra gérer à la fois le container, mais aussi les inputs passés au processus cloisonné.

L'avantage de passer par un orchestrateur de service est d'enlever au service Docker les rôles qui ne sont pas son point fort, comme le démarrage des containers dans un ordre précis, le redémarrage du container si le processus se termine en erreur (option --restart always), le status du processus cloisonné (le container est signalé comme "Up" alors qu'aucun processus n'est actif), et la gestion des logs du processus directement par Journald.

Pour récupérer la sortie standard et l'erreur, bref le log du processus, il faut que le container ne soit pas spawné avec l'option -d (détacher la tâche) pour ne pas qu'il parte en arrière-plan, c'est Systemd qui gère lui-même la partie « démon ». Du point de vue de Systemd, la commande ne forke pas, et toutes les sorties sont recueillies automatiquement par Journald.

Le second avantage est d'obtenir une meilleure intéraction avec le processus cloisonné. Tous les signaux comme SIGINT, SIGKILL et SIGHUP, envoyés par Systemd au container seront transférés par le service Docker directement au processus principal à l'intérieur du container. L'entrée standard reste ouverte si le container est attaché (à un tty ou à Systemd), mais on peut aussi demander de la laisser ouverte quand le container est détaché avec l'option -i.

Le service Docker ne sert plus d'intermédiaire comme un émulateur de VM qui doit relayer les signaux de fin de tâche à tous ses invités. Je serais tenté de croire qu'il y a un gain de temps non-négligeable dans le temps de réponse des processus, mais je n'ai pas fait de benchmark...

Et puis, les choses intéressantes commencent à arriver, on parle de container non-définitif, on parle de cloisonner seulement le processus, et surtout on parle de terminer le processus, tu as deviné la suite mon lecteur. =)

L'idée c'est de pouvoir perdre les containers, mais pas les données personnelles.

J'ai retourné toutes les pistes à fond, je suis même allé jusqu'au "container-boite-noire" (un trip vraiment obscure), mais aucune d'entre-elles ne répondait correctement à ma problèmatique. Si on perd les containers, il faut maitriser le moment de la perte (il ne faut pas que ce soit à un moment aléatoire). Pire encore, il faut recréer rapidement juste après les nouveaux containers qui doivent remplacer les anciens, et ils doivent être instantannément opérationnels sans avoir besoin de faire un quelconque setup manuel.

Il y a un événement que Systemd maitrise et qui pourrait servir de déclencheur à la destruction de l'ancien container. « Le processus se termine, alors je détruis le container. » Il y a une multitude de scénarios possibles, comme par exemple : « Au démarrage du nouveau processus, je détruis l'ancien container, puis je lance le nouveau » Tu remarqueras cher lecteur que lors du premier démarrage, il y aura des erreurs car aucun ancien container n'existe pas au préalable.

Heureusement, le service Docker gère bien ce point (ouf!), il suffit de passer dans la ligne de commande l'option --rm et lorsque le processus se terminera, son container sera détruit automatiquement. Systemd n'aura qu'à spawner les containers et tuer les processus à l'intérieur. C'est ce qu'on attend d'un gestionnaire de services, en fait.

Et donc, si l'on se dit que les données perso n'ont pas besoin d'être isolées, alors on peut les laisser dans un répertoire quelconque sur le disque dur (avec l'option -v).

Volume de données quelconque, mais pas trop, quand même...

Le service Docker va gérer les modes et ownership des fichiers. Si le processus cloisonné les modifie, alors ils changeront sur le disque dur. Il est question seulement des fichiers à l'intérieur du volume exposé, il ne peut pas altérer les fichiers à l'extérieur. Tu remarqueras cher lecteur, que le processus peut changer lui-même les permissions du répertoire racine (le lien entre le volume sur disque et le volume dans le container). Si tu veux que les autres utilisateurs ne puissent pas regarder dedans, tu peux setter manuellement en root les bonnes permissions sur le répertoire parent.

Dans cet optique de permissions, il vaut mieux regrouper les volumes exposés du container dans un seul répertoire par container, pour pouvoir globalement interdire, ou pas, l'accès aux volumes du container aux utilisateurs système.

Okay on gère les droits linux de base, voyons si on peut pas augmenter le level.

SELinux propose une couche d'abstraction supplémentaire à la gestion des droits linux (jugée imparfaite par la NSA), directement au niveau du noyau Linux... mais je radotte, tu le sais déjà mon vieux lecteur. Le service Docker propose une option intéressante pour les systèmes possèdant SELinux. Oui, toute l'arborescence de répertoires exposée sur disque par le container sera cloisonnée par SELinux. Aucun processus, s'il n'a pas le droit de modifier les fichiers ayant le contexte 'svirt_sandbox_file_t', ne pourra JAMAIS altérer cette arborescence. Je sais pas pour toi, mais moi, perso, ça me fait kiffer. On pourrait aller beaucoup plus loin avec le mode Multi Level Security, malheureusement ce n'est pas le mode courant sur mon serveur.

En ligne de commande ça ressemble à ça :
-v /rep/sur/hote:/rep/dans/container:Z

Cette option exécute automatiquement un change context (commande 'chcon') sur les répertoires du disque. Attention pour que ce soit persistent après un restorecon il faut ajouter la règle avec semanage :
semanage fcontext -a -s system_u -t svirt_sandbox_file_t "/contener/mariadb-casper-im(/.*)?"
Dans tous les cas, il faut user et abuser de la commande restorecon pour bien vérifier ses règles, et je t'invite à lire cet article qui m'a sauvé la vie, d'ailleurs.

Pour terminer en beauté, le service Docker ne supprime pas les volumes exposés sur disque. Que ce soit dans le répertoire par défaut (/var/lib/docker/volumes) ou bien un répertoire assigné avec l'option -v, ce répertoire ne sera pas supprimé si le container est volontairement ou involontairement supprimé.

Voici une unité systemd pour le serveur de base de données de ma messagerie instantannée (Jabber) en guise d'exemple :

[Unit]
Description=Mariadb Server Casper IM
After=docker.service

[Service]
Restart=always
EnvironmentFile=/etc/%p.env
ExecStart=/usr/bin/docker run -i --rm --name %p -p 127.0.0.1:16000:3306 \
          -e MYSQL_USER \
          -e MYSQL_PASSWORD \
          -e MYSQL_DATABASE \
          -e MYSQL_ROOT_PASSWORD \
          -v /contener/%p/var/lib/mysql/data:/var/lib/mysql/data:Z \
          -v /contener/%p/etc/my.cnf.d:/etc/my.cnf.d:Z \
          -v /contener/%p/var/log/mariadb:/var/log/mariadb:Z \
          mariadb:10.1.20-8
ExecReload=/usr/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target


Le fichier /etc/mariadb-casper-im.env contient les credentials du serveur Mariadb (user mysql, mot de passe, etc...) Il initialise les variables d'environnement MYSQL_USER, MYSQL_PASSWORD, etc... présentes dans l'unité systemd. Il a aussi le mode 400 car il contient des mots de passe. L'image docker est une image custom basée sur celle de Fedora Cloud (le dépôt Git.) Ma seule modification n'est pas vraiment une contribution, j'ai juste ajouté 2 volumes exposés.

VOLUME ["/var/lib/mysql/data", "/etc/my.cnf.d", "/var/log/mariadb"]

Voici quelques conseils de gestion de disque :
  1. Regrouper les volumes exposés dans un répertoire par container
  2. Regrouper les répertoires de container sur une partition montée
  3. Cette partition devrait être un volume LVM de type miroir
  4. Cette configuration ne dispense pas d'avoir des backups journalier (dump de base de données ou autre)
En parlant backup, n'hésitez pas à vous servir de 'docker exec' pour intéragir avec le programme cloisonné, par exemple :

docker exec -i mariadb-casper-blog  mysqldump --opt -u casperlefantom -p$MYSQL_USER_PASSWORD casperlefantom > db-casperlefantom-$(date +%Y%m%d).dump

Magie, le fichier "db-casperlefantom-20161220.dump" est généré à l'extérieur du container. J'ai volontairement utilisé des exemples avec Mariadb car c'est le programme qui m'a donné le plus de fil à retordre, les autres programmes comme apache pour servir des sites statiques étaient bien plus faciles, sans credentials, sans variables d'environnement, etc... Mais toujours avec backup ;)

[Unit]
Description=Apache HTTP Server Vhost onion1
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run -i --rm --name %p -p 127.0.0.1:8085:80 \
          -v /contener/%p/var/www/html:/var/www/html:Z \
          -v /contener/%p/etc/httpd/conf.d:/etc/httpd/conf.d:Z \
          -v /contener/%p/etc/pki/tls/private:/etc/pki/tls/private:Z \
          -v /contener/%p/etc/pki/tls/certs:/etc/pki/tls/certs:Z \
          -v /contener/%p/var/log/httpd:/var/log/httpd:Z \
          apache-single:2.4.23-2
ExecReload=/usr/bin/docker exec %p /usr/sbin/httpd -k graceful

[Install]
WantedBy=multi-user.target
Pour ajouter de l'orchestration entre les services, on peut jouer avec les options After et BindTo dans la partie [Service] des unités systemd. Indispensable lorsque l'on utilise du linkage entre 2 containers...

Installation à risque: serveur Bitcoin

Matthieu Saulnier

bitcoin-half.png

Je suis devenu complice. Complice de contribuer à l'établissement d'une nouvelle monnaie. Non, pire que ça, complice d'instaurer un nouveau système financier. Aussi révolutionnaire qu'a l'air cette intrigue, c'est pourtant exactement le point de vue du monde de la finance sur le dossier Bitcoin. Pire encore: Bitcoin est un changement non désiré par le monde de la finance, et donc comme toute bonne société panoptique qui se respecte, cette société veut erradiquer Bitcoin. Vouloir changer juste pour changer n'est pas une bonne solution, mais changer pour quelque chose de mieux semble tout à fait astucieux. Voyons plus en détail pourquoi je préfère avoir des bitcoins au lieu d'une poignée d'euros. Je tiens à préciser dès maintenant que qualifier les euros de monnaie "réelle" (éventuellement palpable) est erronné depuis l'invention de la monnaie papier. Les bitcoins et les euros sont aussi virtuels les uns que les autres, sauf que certains remplissent mieux leur rôle que d'autres, d'une manière plus transparente. La plupart des détracteurs du systèmes financier Bitcoin utilisent la peur, car il est vrai que Bitcoin est un système expérimental, donc risqué. Il est tout aussi vrai que le risque de crise économique du système financier actuel existe, pourtant il n'est pas expérimental.

À notre époque, l'époque où nous achetons vraiment tout ce dont on a besoin sur Internet (sauf le pain, mais de toutes façons les boulangeries n'acceptent pas encore les bitcoins), le procédé des transferts d'euros par Internet est véritablement resté identique au processus utilisé dans la vie réelle. Pour transférer une partie de mon argent, je dois demander à mon banquier si j'ai suffisament d'argent pour transférer une certaine somme à ce commerçant, et si oui, de soustraire cette somme de mon compte puis indiquer à la banque du commerçant d'ajouter cette somme sur le compte du commerçant. Ce processus est appliqué lorsque je paye sur Internet, lorsque je paye par carte de crédit, lorsque je paye par espèces. Les espèces sont inclues car elles ne représentent qu'un solde négatif sur un compte (un retrait) et un solde positif sur un autre compte (un dépôt). Si pour vous ce transfert d'argent ressemble à trois tonnes d'opérations intermédiaires juste pour transférer de l'argent, vous n'êtes pas les seuls. Les intermédiaires, c'est pratique et c'est bien, tant que le travail est bien fait. Depuis 2008 nous savons que notre intermédiaire du monde de la finance ne travaille pas si bien que ça, est-ce par cupidité, incompétence, voire même fénéantise, je ne veux pas le savoir. Pour approfondir l'étude du système financier actuellement en activité, je vous invite à regarder le film L'argent Dette de Paul Grignon (2010) sur youtube ou dailymotion.

Le système financier Bitcoin permet de s'affranchir d'un certain nombre de contraintes, basé sur quelques idées simples remontant à l'époque où les humains commerçaient par le troc. Il vise à la suppression des intermédiaires. Dans l'échelle du temps, ce système est constitué de deux grandes phases, la première étant la fabrication de la masse monnétaire par inflation, cette masse ne peut dépasser les 21 millions de bitcoins, puis la phase des échanges renouvelables indispensable au développement durable. Ce contrôle de l'inflation va radicalement à l'opposé du système financier que nous connaissons, et évite ainsi la création de "bulle" d'argent tout en facilitant le libre échange. À l'heure où j'écris ces lignes il est moins intéressant de créer de la monnaie par minage que d'en gagner par échange de services ou de valeurs marchandes, d'ailleurs une grande partie des utilisateurs Bitcoin ne font pas de minage. On pourrait croire que la limite maximale à 21 millions de bitcoins en circulation est insuffisante, c'est faux mais pour le voir il faut changer de point de vue. Un bitcoin est divisible jusqu'à la huitième décimale. Si vous avez 0,00001000BTC vous êtes pauvre, si vous avez 0,00100000BTC vous êtes dans la classe moyenne et pouvez vous offrir plein de choses, si vous avez 0,10000000BTC le monde vous appartient. Le changement d'échelle numérique est toujours un peu perturbant au début. De plus, tout l'argent que je possède est présent sur mon ordinateur qui prend donc le rôle de porte-feuille électronique, sans un seul intermédiaire. Si je réplique mon ordinateur, je n'aurais pas le double d'argent bien sûr, et si je perds mon ordinateur il se passe la même chose que si je perdais mon porte-monnaie. C'est dans cet esprit d'équité et de simplicité qu'a été conçu Bitcoin.

L'unicité de chaque bitcoin présent dans mon porte-feuille est garanti par la mise en application de la cryptographie. Ainsi, si je donne un bitcoin à une personne il disparait définitivement de mon porte-feuille pour réaparaitre dans le siens. L'inverse est vrai, si quelqu'un me donne un bitcoin il ne pourra pas utiliser ce même bitcoin pour une autre transaction. Pour qu'il y ait transaction, nous sommes habitués dans le monde de la finance à devoir communiquer des information d'identification (prénom, nom, adresse postale), mais une fois encore le système financier Bitcoin se veut le plus simple. Il suffit de demander à son porte-feuille de générer une adresse Bitcoin, cette adresse est unique et vous appartient, elle vous permet d'effectuer un débit du solde de votre porte-feuille lorsque vous la communiquez à une autre personne. Selon le même principe, si je veux que quelqu'un puisse me transférer de l'argent, il suffit de demander à mon porte-feuille de générer une adresse Bitcoin qui permettra d'effectuer un crédit du solde de mon porte-feuille lorsque je la communique à une personne tierce. Au cours de ces transactions, je n'ai pas eu à fournir des informations d'identification donc mon anonymat est préservé. L'adresse Bitcoin ne fait pas seulement office d'identifiant de transaction, on peut la réutiliser plusieurs fois. Elle s'apparente plutôt à un compte bancaire et votre porte-feuille en serait la banque titulaire. Le solde d'une adresse peut donc être positif si cette adresse a servi à transferer de l'argent vers votre porte-feuille, ou bien négatif si l'adresse a servi à transférer de l'argent vers un autre porte-feuille. Le seul solde qui doit être positif ou nul étant celui de votre porte-feuille, et il est calculé en additionnant les soldes de toutes les adresses.

Chacun est son propre banquier certes, mais qu'est-ce qui empècherait d'effectuer des transactions frauduleuses en falsifiant son propre livre des comptes ? Avec un livre des comptes publique bien sûr, disponible au téléchargement pour tous, il est nommé Blockchain. À chaque transaction, le porte-feuille destinataire est informé de son crédit et l'inscrit dans son livre des comptes, et le porte-feuille débiteur inscrit l'opération de débit dans son livre des comptes, puis ils informent *tout* le réseau Bitcoin de cette transaction conclue. Les deux partis prennent le monde à témoin, et chaque témoin va inscrire cette transaction dans son propre livre des comptes. C'est pour cette raison que le système financier Bitcoin est neutre et acentré, le solde de chaque porte-feuille peut être retrouvé à partir du livre des comptes publique. Le réseau Bitcoin est en perpétuelle synchronisation, il se compose de toutes les personnes ayant un porte-feuille et le logiciel en cours de fonctionnement sur son ordinateur. C'est ici que je rejoins le titre de l'article après cette longue introduction, installer sur Fedora le logiciel bitcoin pour, en plus d'avoir un porte-feuille avec un solde nul ou éventuellement positif, être le témoin d'un système financier vraiment bien conçu et pouvoir accepter des valeurs dans cette devise.

L'installation doit se faire obligatoirement dans une machine virtuelle, car les RPMs que j'ai récupéré et modifié ne sont vraiment pas beaux, mais j'ai pas réussi à les améliorer hélas. Il ne faut en aucun les installer sur son système principal. Seconde précaution, prévoir un volume logique de 40Gio pour /var/lib/bitcoin/, ce répertoire va accueillir le fameux livre des compte publique qui pèse déjà 17Gio dans la balance. Enfin, prévoir le routage du port d'écoute 8333 depuis le routeur jusqu'à la VM afin de pouvoir remplir le rôle "serveur". Les RPMs sources que j'ai utilisé proviennent du développeur de RingingLiberty.com qui maintient ces paquets depuis un moment déjà. Les seules modifications que j'y ai apporté sont l'utilisation du fichier d'unité systemd pour le service ainsi qu'une mise à jour du programme. En aucun cas je ne recommande d'installer ces paquets sans en avoir examiné les sources, mes paquets ne sont pas plus dignes de confiance que les siens, le minimum syndical étant des les recompiler à partir des sources. Pour l'installation minimale les paquets suivants sont nécessaires :

openssl-compat-bitcoin-libs-1.0.1g-0.1.fc20.x86_64
bitcoin-server-0.9.2-1.fc20.x86_64
openssl-compat-bitcoin-1.0.1g-0.1.fc20.x86_64
bitcoin-cli-0.9.2-1.fc20.x86_64
bitcoin-0.9.2-1.fc20.x86_64

Puis il faut configurer le service avant de le démarrer :

# cat /var/lib/bitcoin/.bitcoin/bitcoin.conf
rpcuser=bitcoinrpc
rpcpassword=INSERT_A_RANDOM_STRING_HERE

Veuillez à avoir les bonnes permissions pour le fichier ainsi que ses répertoires parents :

# ll -a /var/lib/bitcoin/.bitcoin/|head -4
total 7428
drwxr-xr-x. 5 bitcoin bitcoin    4096 23 juil. 18:11 .
drwxr-x---. 3 bitcoin bitcoin    4096  7 juil. 13:17 ..
-rw-------. 1 bitcoin bitcoin      76 13 juil. 02:25 bitcoin.conf

Maintenant vous pouvez activer et démarrer le service :

# systemctl enable bitcoin
# systemctl start bitcoin

Juste après le démarrage du service, le démon va commencer par télécharger la blockchain de 17Gio, ce qui risque de prendre 1 ou 2 jours selon la vitesse de téléchargement. Une fois synchronisé, le serveur ne consomme pas trop de resources réseau, et la charge CPU baisse significativement. À partir de là vous avez un serveur Bitcoin opérationnel qui enregistre des transactions, maintenant voyons votre porte-feuille. Toutes les commandes pour contrôler votre porte-feuille sont de type :

$ bitcoin-cli -rpcuser=bitcoinrpc -rpcpassword=MA_PHRASE_PASSE_SUPER_LONGUE <commande>

Remplacer <commande> par "help" pour afficher la liste de toutes les commandes disponibles. Et pour afficher l'aide pour une commande particulière, taper "help <commande>". Pour créer une adresse pour recevoir des bitcoins, on utilise la commande :

getaccountaddress "nom_du_compte"

N'oubliez pas que cette adresse représente un compte et que son historique des transactions est publique. Pour consulter le solde du porte-feuille :

getbalance

La monnaie n'a de valeur que si on lui accorde notre confiance pour remplir le rôle que nous lui avons confié. Il ne vous reste plus qu'à lire beaucoup de documentations sur le système Bitcoin pour vraiment bien appréhender les possibilités sans limite qu'il a à nous offrir. Beaucoup de commerces en ligne acceptent déjà les bitcoins, mais il pourrait y en avoir encore plus à condition d'en faire la demande...