PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Comment gérer mon héritage numérique ?

mercredi 22 novembre 2017 à 18:30

Je me fais opérer vendredi, pour un problème bien maîtrisé en France et par un chirurgien expérimenté, mais il n’y a jamais de risque zéro. Je ne voulais pas trop y repenser mais mon cerveau étant ce qu’il est, j’ai continué à réfléchir sur le sujet : que va devenir ma présence numérique une fois décédé, et comment la transmettre pour qu’elle persiste (au moins une partie, comme ce blog) et que rien ne soit exploité à mon insu après ma mort ?

Faire le point sur ma présence en ligne demande de remettre la main sur l’intégralité des comptes utilisateurs /clients que j’ai pu créer et utiliser au fil des années sur les différents sites. Et la liste est incroyablement longue : vente en ligne, forums, services gouvernementaux, plateformes diverses… En fait, il est préférable de déjà utiliser un gestionnaire de mots de passe dans cette situation, car ça permet de n’avoir qu’un seul élément à transmettre. Mais je n’ai pas eu le temps de faire les choses proprement, c’est donc le tableau ODS qui sera disponible.

D’un point de vue « légal », le statut notamment des comptes de réseaux sociaux après une disparition est plutôt flou, j’ai du fouiller dans les pires recoins des cgu Twitter pour tenter de savoir à quoi m’en tenir. J’ai carrément contacté Google pour savoir comment passer le compte en lecture, pour qu’il ne soit plus utilisable mais que les vidéos YouTube restent en ligne. Je n’ai rien trouvé de probant, on n’est pourtant pas immortel.

J’ai regardé s’il y avait des procédures pour clôturer les comptes de vente en ligne (ldlc Amazon, cdisount, darty, et j’en passe- j’ai même un compte fnac dont je n’arrive pas à retrouver les morceaux). La procédure sur PayPal est un peu contraignante, pour ma banque ma maman pourra gérer puisqu’elle se trouve à 5kms de chez elle.

Pour certains lieux où j’ai publié du contenu, il ne faudrait pas que ce contenu disparaisse avec le compte rattaché. C’est pas toujours évident, j’ai du récemment restaurer une base de données WordPress parce qu’à la suppression d’un compte le contenu n’avait pas été transféré sur un autre, du coup je sais pas trop comment certains moteurs gèrent cette situation. Tant pis donc.

Concernant les services que je paie tous les mois ou tous les ans, il est nécessaire de s’attarder sur le transfert de propriété dans certains cas, sur le budget dans d’autres. Pour le serveur du blog c’est simple, je n’en paie qu’une partie et Arowan a les mêmes pouvoirs que moi donc il est entre de bonnes mains (d’ailleurs administrativement parlant le serveur ne nous appartient pas). Pour les domaines c’est presque aussi simple.

Quant au matériel chez moi, il faut bien également en faire quelque chose. Il y a des chances que ma petite sœur, qui va bientôt avoir assez d’espace, profite de mon pc de jeu et de ses deux écrans. La ps4 et la Xboite aussi, plus pour le beau frère d’ailleurs. Et mon sabre laser et la TV aussi tant qu’on y est. Le micro serveur peut très facilement être reconverti en appareil de bureau pour une école, mon laptop ldlc devrait être transmis aux gens de Parinux pour éventuellement offrir à une personne dont l’appareil présenté à un premier samedi pour un sauvetage de la dernière chance serait irrécupérable. Le Chromebook doit être refilé à un geek qui saura réussir là où j’échoue pour l’instant à savoir virer chromeOS pour ne conserver qu’un vrai Linux. Pour le téléphone vu les pépins que j’ai avec pareil, un bon bricoleur pourra s’en charger et virer oxygen pour y placer lineage en espérant que ça améliore les choses. Mon entourage proche n’aura pas l’utilité d’un raspberry pi 3, par contre mon collègue Simon sera ravi de pouvoir mettre son pi1 à la retraite.


Pourquoi ce billet qui peut paraître sombre ? Si je me répète en indiquant que le risque zéro n’existe pas en médecine, c’est aussi et surtout par expérience personnelle. Quand mon père est décédé, c’était lors d’une opération qui ne devait pas non plus être aussi lourde. Et c’est un évènement qui a été particulièrement impactant dans ma vie, encore aujourd’hui parce qu’il a fallu 10 ans pour que je sois enfin décidé à me faire opérer par peur irrationnelle de rester sur la table. Quand bien même je suis le premier à encourager quelqu’un qui a également besoin de réparer quelque chose, surtout dans notre pays où on a pas besoin de vendre sa maison pour ce genre d’intervention,et où globalement quoi qu’on en dise la qualité des soins et les compétences sont là.

Bref tout ça pour dire que j’ai encore la trouille même si j’ai pu dépasser en partie. Donc si après le 24 novembre vous n’avez pas de nouvelles, et bien que voulez-vous, ça aura été une expérience courte (oui j’ai 35 ans, mais euh !), mais enrichissante. Sinon vous m’aurez encore dans les pattes pendant quelques années encore. Ça serait cool.

Cas d’usage d’Haproxy pour déporter du trafic en fonction de l’URI

lundi 20 novembre 2017 à 18:30

Haproxy est un outil toujours plus intéressant à mesure que je met les mains dedans (même si c’est parfois pénible, quand on manipule deux versions différentes dans la même journée — coucou la page de stats). Ici, j’aimerai vous présenter un petit cas pratique de séparation de traitement sur une même ferme en fonction de l’URI. Eh oui, c’est possible, et c’est super simple en fait.

Contexte

Le client propose, au travers de son site Web, une API REST, via une URL de type /rest/*. Rien de choquant me direz-vous, à part que le système n’est pas des plus performants (code maison pas super maîtrisé), et tend à ralentir le reste du site complet (car c’est bien PHP le consommateur dans l’histoire, la base de données qui se trouve sur un serveur à part fait très bien son boulot, quand elle en a à faire). Il dispose déjà de deux frontaux webs (Apache +PHP-FPM), derrière un load-balancer haproxy donc. Une solution est proposée de monter un troisième front qui sera dédié à l’API, pour ne plus impacter la consommation de CPU des pools principaux. Mais comme tout ce petit monde travaille sur le même domaine, et passe donc par Haproxy, plutôt que de jouer au dégueulasse avec des ProxyPass dans Apache, on peut faire ça bien, propre, élégant, au bon endroit.

ACL : magie magie…

Une fois n’est pas coutume on crée deux « backends » : un pour l’API, l’autre pour le reste du site :

backend site-api
    server rest 3.3.3.3:80 check

backend site-back
    balance source
    server web1 1.1.1.1:80 check
    server web2 2.2.2.2:80 check

Voilà, rien de super choquant, c’est pas super complet mais c’est pour l’exemple. Attardons nous maintenant sur le « frontend », car c’est à son niveau que l’on va finalement intervenir :

frontend site
    bind *:80
    mode http
    acl rest path_beg /rest/
    use_backend site-api if rest
    default_backend site-back

Voilà, c’est aussi simple que ça (oui bon faut savoir que ça existe et faut se fader la doc qui est pas la plus claire du monde, j’avoue). Il faudra juste, si vous ajoutez des conditions (ou par exemple, une redirection vers HTTPS), faire attention à l’ordre des directives, mais si vous testez correctement la configuration, Haproxy vous préviendra de ce qui ne lui plaira pas.

Pleins d’usages possibles en fonction des applications

Ici, j’utilise les ACL pour des raisons fonctionnelles, le concept pourrait être le même pour séparer un back-office d’un front-office, pour présenter une versions légèrement différente de l’application en fonction de certains critères (pour faire du beta testing, ou que sais-je d’autres)… Mais pendant que je testais la solution, un autre cas d’usage m’est apparu via le Journal du Hacker qui va s’avérer pratique pour un autre de mes projets clients : la gestion d’un certificat Let’s Encrypt avec Haproxy. C’est présenté sous OpenBSD, mais finalement la solution fonctionne parfaitement sous Linux (j’ai utilisé nginx-light sous Debian), il suffit d’adapter très peu de chose, tel que le rechargement de configuration qui est évidemment différent.

Et vous, quel usage des ACL faites-vous dans Haproxy ?

Causons un peu de santé (la mienne en l’occurrence)

samedi 18 novembre 2017 à 10:30

À force de me demander si « c’est pas trop grave » quand j’évoque mon opération prochaine, on va faire une petite mise au point pour éviter d’avoir à en reparler. Surtout que c’est pas sorcier, c’est pas « grave », c’est juste chiant et ça traîne depuis trop longtemps.

Je vais me faire opérer pour réparer une hernie inguinale. Pour la faire courte, un bout de mon intestin a quitté l’abdomen via le canal inguinal, élargi lors de mon activité de magasinier et de maçon (un parcours chaotique vous en conviendrez), et cohabite maintenant depuis quelques années avec un de mes testicules. Comme d’habitude, Wikipédia vous en dira plus si tant est que vous comprenez tout ce que dit l’article.

C’est sexy n’est-ce pas ? Je vous épargne les photos, de toute façon, il vous suffira de vous rendre sur votre moteur de recherche favori pour voir la joie que ça représente. Mais je risque quoi avec ça ? Principalement, une occlusion intestinale, avec à la clé la mort dans les six heures. Et ma mère est déjà passée par là (prise en charge à temps, fort heureusement), donc je sais que c’est moyen. Sinon, parfois le morceau d’intestin s’enflamme un peu et c’est douloureux, les pires « crises » me bloquant complètement pendant quelques secondes à quelques minutes, à ne plus pouvoir tenir debout. Mais c’est devenu extrêmement rare, surtout depuis que je ne suis plus travailleur manuel (dans le sens où je dois produire un effort physique significatif). Dernier désagrément, un transit intestinal parfois contrarié. Je vous l’ai dit que c’était sexy ?

Et on a l’avantage, en France, d’avoir les compétences et les infrastructures pour que l’opération se déroule dans de bonnes conditions. Jugez donc : ça se passera en ambulatoire, ce qui veut dire que je rentre le matin (tôt), je me fais opérer (une bonne heure d’après le chirurgien), et si le soir il n’y a rien de particulier à signaler, je rentre chez moi (enfin en l’occurrence, chez ma maman), avec deux semaines d’arrêt maladie, et une semaine de bas de contention pour limiter un risque de phlébite. Restera ensuite une attente de deux mois avant de pouvoir vraiment réexploiter pleinement mon corps. Évidemment le risque zéro n’existe pas, mais c’est un sujet assez maîtrisé, et je vais être pris en charge par un chirurgien pas mal expérimenté.

Le plus débile finalement, et qui est lié à différentes expériences personnelles que je ne vais pas étaler aujourd’hui parce que ce n’est pas une séance de psychologie, c’est que j’ai mis presque une dizaine d’années à me décider à me faire opérer. Une première étape d’un plan plus général pour me délester de quelques kilos en trop qui commencent non seulement à peser salement sur mes chevilles et mes genoux, mais également sur ma tension, et donc mon cœur. À 35 ans c’est un peu con, surtout quand je repense au niveau d’activités que j’avais en sortie de lycée.

Bref, une fois réparé, je vais pouvoir rebouger un peu, et pourquoi pas enfin me servir de mon sabre laser pour pratiquer à la Sport Saber League de France. En plus c’est drôle ça fait SSL.

APT vs Windows Update, oui mais…

vendredi 17 novembre 2017 à 18:30

Je viens de voir que j’ai pas mal de retard sur le blog, il est vrai que ces derniers temps beaucoup de boulot de fond ou hors monde numérique donc le blog passe après. En attendant la finalisation de quelques articles un peu plus étoffés, j’aimerai apporter mon éclairage à cet article du blog de Tesla comparant les mises à jour apt Debian contre Windows. Parce qu’on ne peut pas commenter, et qu’il y a deux trois trucs à rappeler.

NB : pour les plus casses-couilles qui me penseraient vendus à Debian, la remarque vaut aussi bien pour APT que pour YUM/RPM, Pacman, et même Gentoo/emerge. Pratiquement tous les systèmes de packaging sous Linux en fait.

Il y a une différence fondamentale dans la construction des systèmes Debian et Windows : le premier est entièrement construit à partir des paquets qui sont fournis sur les dépôts, alors que Microsoft construit son image direct à partir des sources pour ensuite ne proposer que des patches.

Le mot patch est important : en fait, à chaque mise à jour d’un composant, sous Debian vous récupérez l’intégralité de ce composant comme si vous l’installiez pour la première fois. Seule votre configuration est conservée. Et ce quand bien même la mise à jour ne concerne, sous le capot, qu’une partie des fichiers du paquet en question. Microsoft, au contraire, ne va proposer au travers d’une mise à jour que le strict nécessaire à la mise à jour d’un de ses morceaux. La conséquence c’est que parfois ils font du patch de patch, donc vous devez effectivement enchaîner les mises à jour et parfois les redémarrages pour pouvoir arriver à un système à jour, ce qui est, je suis d’accord, infiniment frustrant et pénible.

La cause profonde sera difficile à corriger : sous Windows, et même si ce n’est pas toujours parfait, il y a un fort contrôle d’intégrité des fichiers de base du système, qui interdit toute modification à chaud. Ce qui impose un redémarrage pour appliquer les modifications et les tables de contrôle avant le chargement des composants à jour. Un mécanisme qui n’est pas présent par défaut sous Debian et dérivés.

Il y a un cependant un gros inconvénient aux paquets complets : la consommation de bande passante. Pour être sous Manjaro, petite fille d’ArchLinux, les mises à jour qui se produisent toutes les semaines voire tous les 15 jours pèsent en moyenne 300 à 400 Mo. En dehors des mauvais mois Microsoft vous impose une centaine de Mo le deuxième mardi de chaque mois, un peu plus certes si vous mangez cher avec Office. Si vous êtes contraint de survivre sur connexion 3g/4g, avec un forfait data particulièrement contraint vu les usages récents, c’est pas la joie (me souviens avoir mangé 4Go en une heure sur les 5 mensuels que contenait mon forfait d’alors–c’était il y a un peu plus d’un an). Et tout le monde n’a pas encore de fibre optique au niveau résidentiel, en particulier les structures disposant d’une dizaine de machines au minimum comme les écoles (bisou Cyrille, courage pour les salles infos).

D’ailleurs, ce comportement du « package complet » se retrouve sous Windows pour d’autres couches que l’OS. Les « g@merz » savent combien pèsent les nouveaux drivers de cartes graphiques de nos jours qui sont obligatoires ou presque à chaque sortie de nouveau jeu : celui pour ma carte graphique sous Windows 7 me coûtera quasiment 400Mo. Les utilisateurs de Libre office qui suivent les mises à jour se mangent 200Mo à chaque release. Et je pourrais certainement trouver masse d’autres exemples.

Mais je confirme que c’est plaisant, quand on réinstalle, de gagner un temps fou sous Linux en ayant qu’une seule passe à faire, surtout qu’elle peut être lancée en même temps, et donc on a pas l’impression d’être interrompu avant de pouvoir réellement utiliser son ordinateur. Mais à moins de passer ses journées à faire et refaire des installations, c’est un avantage qui ne se voit pas souvent.

Reste le fait qu’on installe tous ses logiciels sous Linux via le même gestionnaire de paquets, là où Windows Update est réservé aux mises à jour (il porte finalement très bien son nom). Pour le reste il faut se taper le Windows Store et donc se faire espionner par Microsoft et ses partenaires publicitaires (car ça demande un compte Microsoft, comme si nous étions sur mobile). Ou continuer à gérer ses logiciels à la main comme un grand, même si des solutions comme WAPT ou Chocolatey commencent à émerger. Elle est pas belle l’informatique « de bureau Windows » de 2017 ?

Gogs : mettre en place un miroir vers GitHub

jeudi 9 novembre 2017 à 18:30

Pour ceux qui ne connaissent pas, Gogs est un service Git auto-hébergé pour gérer vos dépôts de codes. J’avais tenté l’installation du très puissant Gitlab mais ce dernier consomme beaucoup trop de ressources pour qu’il reste un candidat sur mon micro-serveur. Après avoir un peu souffert à l’installation (je détaille pas mais je l’ai cherché), j’ai commencé réellement à bosser avec récemment. Et pour certains des dépôts, je souhaite qu’il soient recopiés sur GitHub, si possible automatiquement. Et c’est assez facile à mettre en place en fait.

Rapide contexte

Gogs est écrit en langage go. Son installation et sa configuration se veulent simplifiées, mais j’ai complexifié le truc « exprès » pour m’exercer un peu sur Postgresql. Il est même possible de l’installer via Docker, et il n’est pas impossible que je déporte mon installation actuelle ou que je la refasse pour basculer sur le cluster Swarm que j’essaie désespérément de monter.

La spécificité c’est donc qu’il est auto-hébergé, nécessairement privé. Mais j’ai également un compte GitHub, et si on pouvait faire en sorte de pousser automatiquement sur GitHub quand on pousse sur Gogs, c’est cool. Sans avoir besoin de la puissance de l’option intégration continue d’un Gitlab beaucoup trop lourd pour mes besoins persos, on a quand même les hooks, qui sont une fonctionnalité de Git.

Quelques étapes simples

En premier lieu, configurer l’accès SSH entre l’instance Gogs et Github. Pour ça, on se connecte sur gogs, et on bascule sur l’utilisateur git qui est celui utilisé par le logiciel. Il faut ensuite se créer une clé SSH, pour ma part je n’ai pas configuré de passphrase :

git@gogs:~/.ssh$ man ssh-keygen 
git@gogs:~/.ssh$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/git/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/git/.ssh/id_ed25519.
Your public key has been saved in /home/git/.ssh/id_ed25519.pub.
The key fingerprint is:
4d:d5:cb:a4:9f:0a:93:1b:13:9c:d3:8d:23:3e:a6:11 git@gogs
The key's randomart image is:
+--[ED25519 256]--+
|            ..   |
|           .  o  |
|         ..o * . |
|        Eo* = +  |
|        So.= o . |
|        . X   o  |
|         + B .   |
|        . . .    |
|                 |
+-----------------+
git@gogs:~/.ssh$ cat id_ed25519.pub 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBeo5HVJCBAggpcSh9RPgUMgg0710etf21sNChjllJyf git@gogs

On ajoute ensuite cette clé sur son compte GitHub via l’interface web :

Tant qu’on est sur GitHub, profitons-en pour créer un dépôt vide, avec le nom qu’un veut. Par feignantise, j’ai utilisé le même que celui du dépôt privé. Attention, il faut absolument qu’il soit vide de tout, il ne faut donc pas sélectionner de licence ou de README.md dans le formulaire de création, sinon techniquement il y aura déjà un commit et ça sera l’enfer pour l’exploiter.

On teste maintenant la connexion depuis Gogs :

git@gogs:~/.ssh$ ssh git@github.com
The authenticity of host 'github.com (192.30.253.112)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.253.112' (RSA) to the list of known hosts.
PTY allocation request failed on channel 0
Hi seboss666! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

Parfait. Rendons-nous maintenant sur l’interface web de Gogs pour y configurer un hook. Pour cela, il faut sélectionner l’un de vos dépôts, se rendre dans les paramètres de ce dépôt, il y a un menu Git hooks :

Il faut modifier le post-receive, qui est vide pour l’instant, et ajouter les lignes suivantes :

#!/bin/bash
git push --mirror git@github.com:seboss666/misc-scripts.git

On enregistre, et… c’est tout. Lors de votre prochain push sur le dépôt, il va ensuite automatiquement renvoyer les modifications sur GitHub :

[seboss666@seboss666-ltp ~/dev/misc-scripts (master) ]$ git push origin master
Décompte des objets: 3, fait.
Delta compression using up to 4 threads.
Compression des objets: 100% (3/3), fait.
Écriture des objets: 100% (3/3), 403 bytes | 403.00 KiB/s, fait.
Total 3 (delta 1), reused 0 (delta 0)
remote: Warning: Permanently added the RSA host key for IP address '192.30.253.113' to the list of known hosts.
remote: To git@github.com:seboss666/misc-scripts.git
remote:  * [new branch]      master -> master
To ssh://gogs.seboss666.ovh/Seboss666/misc-scripts
   f2d9016..47ef107  master -> master

Voilà, maintenant, je vais pouvoir reprendre petit à petit les différentes broutilles que j’ai pu vous balancer au fil des années sur le blog et les ajouter là-dedans. En passant, l’utilisation via mon rebond SSH fonctionne très bien pour taper sur mon instance Gogs 🙂

PS : J’indique qu’il ne faut pas ajouter la licence sur le dépôt créé sur GitHub, je l’avais fait sur Gogs, et GitHub a détecté le fichier et affiche correctement la licence sur la page du dépôt 😉