yannic/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

structure & meta

Browse source
This commit is contained in:
Yax 2019-08-17 18:40:27 +02:00
parent da6d838193
commit b25ce65735
284 changed files with 461 additions and 1000 deletions
Download patch file Download diff file Expand all files Collapse all files

43
posts/2017/2017-01-29-ne-pas-couper-branche.md Executable file
View file

@ -0,0 +1,43 @@
<!-- title: Ne pas couper la branche -->
<!-- category: Hébergement -->
<!-- tag: planet -->
Je continue à héberger mes services personnels sur un serveur Dedibox propulsé
par une Debian.<!-- more --> En 2016, j'ai rajouté deux services : mon instance de
[Wallbag](https://wallabag.org/fr) et le [serveur de
mail](http://blogduyax.madyanne.fr/peu-de-neuf.html) du domaine *madyanne.fr* à
ceux existants : mon lecteur de flux RSS (Tiny Tiny RSS), mon cloud (NextCloud)
et ce blog. La reprise en main des e-mails a été une très bonne idée, c'est
formateur et on décide des limites : le nombre de comptes et d'alias, l'espace
de stockage alloué à chaque compte.
Mais il faut penser qu'en cas de panne du serveur, on n'a plus d'e-mail et
surtout pas d'alerte à moins d'utiliser un e-mail alternatif. J'utilise mon
e-mail *@madyanne.fr* pour l'ensemble des services mais il faut faire une
exception pour Gandi qui gère mes DNS et Online qui héberge mon serveur. Sinon,
je ne suis pas prêt de recevoir une notification en cas d'interruption de
service du serveur de mail.
J'aurais pu me servir de mon e-mail Google, qui me sert seulement pour
accéder au Play Store avec mes équipements Android, mais ses e-mails sont
récupérés par *madyanne.fr* grâce à Fetchmail. J'ai donc dépoussiéré un vieil
e-mail Free, inutilisé depuis 15 ans, inconnu des spammeurs et je l'ai ajouté
comme e-mail d'alerte chez Online et Gandi. En prime, j'ai créé un compte sur
[Uptime Robot](https://uptimerobot.com) qui vérifie que le blog est accessible
toutes les 5 minutes et m'envoie une alerte e-mail sur mon compte principal et
chez Free.
Bon c'est pas mal, je n'ai pas coupé la branche sur laquelle je suis assis : si
le serveur de mail tombe, j'aurais des alertes... à condition de vérifier
régulièrement la boite de réception de mon e-mail chez Free. Ca veut dire
rajouter gérer deux comptes e-mails sur mon téléphone et je n'ai pas envie de
cette contrainte. L'idéal serait de recevoir un SMS si un e-mail arrive chez
Free, ce qui doit être exceptionnel car symptomatique de gros problème. Me
voici donc en quête d'un service gratuit d'envoi de SMS et après diverses
pérégrinations j'ai fini sur [IFTTT](https://ifttt.com). Bon c'est gratuit donc
c'est probablement moi le produit et ne sachant pas trop quel est le *business
model* de IFTTT je ne sais pas encore quelle part de mon âme j'ai bradé Si
vous avez une alternative pas chère pour cette partie d'envoi de SMS je suis
intéressé.

52
posts/2017/2017-02-02-extensions-firefox.md Executable file
View file

@ -0,0 +1,52 @@
<!-- title: Mes extensions Firefox en 2017 -->
<!-- category: Mozilla -->
<!-- tag: planet -->
2017 est une année charnière pour la Fondation Mozilla qui doit convaincre que
Firefox reste son fer de lance dans la lutte pour les standards ouverts du Web.<!-- more -->
Certes ils ont commis des erreurs de gouvernance : l'abandon de FirefoxOS qui
avait déjà une base d'utilisateurs, le rêve de pouvoir mettre un orteil dans le
domaine des objets connectés face à des sociétés qui en ont fait leur cheval de
croissance pour les prochaines années. Mais la meute des utilisateurs
mécontents devrait se calmer, reconnaître ce que Mozilla a apporté au Web et
soutenir Firefox car ce n'est pas le moment de déserter. Mozilla a besoin de
sa base d'utilisateurs pour pouvoir financer les évolutions majeures annoncées
en 2017.
[Trois ans plus
tard](http://blogduyax.madyanne.fr/mes-extensions-firefox.html), je refais la
liste des extensions que j'utilise quotidiennement ; pas de révolution mais des
mises à jour sur les thèmes qui me tiennent à coeur : sécurité de navigation,
protection de la vie privée. Quand je relis ma liste, je ne vois aucune
alternative crédible à Firefox.
**Navigation améliorée**
- [uBlock Origin](https://addons.mozilla.org/fr/firefox/addon/ublock-origin/?src=ss) : bloqueur de pub
- [Wallabag](https://addons.mozilla.org/fr/firefox/addon/wallabag-v2/) : sauvegarde de la page dans Wallabag pour lecture ultérieure
- [Nimbus](https://addons.mozilla.org/fr/firefox/addon/nimbus-screenshot) : capture d'écran
- [I Don't care about cookies](https://addons.mozilla.org/fr/firefox/addon/i-dont-care-about-cookies/?src=api) : accepte les bandeaux officiel informant que le site enregistre des cookies
**Sécurité**
- [HTTPS Everywhere](https://www.eff.org/https-everywhere) : forcer l'utilisation de HTTPS au lieu de HTTP.
- [YesScript](https://addons.mozilla.org/fr/firefox/addon/yesscript/?src=api) : liste noire de blocage JavaScript
- [Popup Blocker Ultimate](https://addons.mozilla.org/fr/firefox/addon/popup-blocker-ultimate) : blocage des popups
- [Flagfox](https://addons.mozilla.org/fr/firefox/addon/flagfox/?src=search) : affiche le drapeau du pays où est situé le site Web et procure des outils de vérification
**Protection de la vie privée**
- [Privacy Badger](https://addons.mozilla.org/fr/firefox/addon/privacy-badger17/) : bloquer
les mouchards du Web.
- [Cookies Exterminator](https://addons.mozilla.org/fr/firefox/addon/cookies-exterminator) : suppression des cookies à la fermeture des onglets.
- [Google Search Link Fix](https://addons.mozilla.org/fr/firefox/addon/google-search-link-fix) : supprime les redirections de lien des pages de résultat de Google
**Développement Web**
- [Wappalyzer](https://wappalyzer.com) : une extension qui dévoile les technologies utilisées par les sites web
- [SQLite Manager](https://addons.mozilla.org/fr/firefox/addon/sqlite-manager) : gestion de bases de donnée SQLite
- [Simple Locale Switcher](https://addons.mozilla.org/fr/firefox/addon/simple-locale-switcher) : changement de langue de l'interface utilisateur
- [Firestorage Plus](https://addons.mozilla.org/fr/firefox/addon/firestorage-plus/?src=search) : inspection du stockage local
- [Firebreak](https://addons.mozilla.org/fr/firefox/addon/firebreak/?src=search) : trouver le point de rupture dans les *responsive designs*
- [En-tête HTTP](http://livehttpheaders.mozdev.org) : afficher les en-têtes HTTP
- [Cookie Manager](https://addons.mozilla.org/en-US/firefox/addon/cookies-manager-plus) : gestion des cookies installés

99
posts/2017/2017-02-10-serveur-svn.md Executable file
View file

@ -0,0 +1,99 @@
<!-- title: Un serveur SVN en 5 minutes -->
<!-- category: Développement -->
<!-- tag: planet -->
Bien qu'on soit en 2017, on peut avoir besoin d'un gestionnaire de source
centralisé et Subversion reste une valeur sure.<!-- more --> On va donc s'installer un
serveur SVN sur Debian Jessie en 5 minutes chrono.
D'abord on installe SVN et on crée un répertoire pour les données.
$ apt-get install subversion
$ mkdir -p /srv/svn/repos
Et on initialise un dépôt (aka *repository*) nommé "yaxsoft".
$ svnadmin create /svn/repos/yaxsoft
On ajoute des droits d'accès simples : un utilisateur en lecture-écriture, pas
d'accès anonyme.
Editer */srv/svn/repos/yaxsoft/svnserve.conf* :
[general]
password-db = passwd
authz-db = authz
realm = Yax Repo
Editer */srv/svn/repos/yaxsoft/conf/authz* :
[groups]
dev = yannic
[/]
* =
@dev = rw
Editer */srv/svn/repos/yaxsoft/conf/passwd* :
[users]
yannic = mon_mot_de_passe
On crée un répertoire pour les logs :
$ mkdir -p /var/log/svn
On ajoute un utilisateur UNIX *svn* qui va lancer le serveur et aura les
permission sur les fichiers de données :
$ adduser svn --system --disabled-login --no-create-home --group
$ chown -R svn:svn /srv/svn /var/log/svn
On crée le fichier avec les paramètres de lancement du service */etc/default/svnserve* :
DAEMON_ARGS="--daemon --pid-file /srv/svn/svnserve.pid --root /srv/svn/repos --log-file /var/log/svn/svnserve.log"
Enfin, on définit le recyclage des logs avec un fichier */etc/logrotate.d/svn* :
/var/log/svn/*.log {
daily
missingok
rotate 10
compress
notifempty
create 640 svn svn
sharedscripts
postrotate
if /bin/systemctl status svnserve > /dev/null ; then \
/bin/systemctl restart svnserve > /dev/null; \
fi;
endscript
}
Il reste à créer un fichier de lancement pour **systemd** : */etc/systemd/system/svnserve.service* :
[Unit]
Description=Subversion daemon
After=syslog.target network.target
[Service]
Type=forking
PIDFile=/srv/svn/svnserve.pid
EnvironmentFile=/etc/default/svnserve
ExecStart=/usr/bin/svnserve $DAEMON_ARGS
ExecReload=/bin/kill -s SIGHUP $MAINPID
User=svn
Group=svn
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target
Finalement, on met le service en démarrage automatique et on lance notre serveur SVN :
$ systemctl daemon-reload
$ systemctl enable svnserve
$ systemctl start svnserve
Notre SVN est accessible en **svn://mon_serveur/yaxsoft**.

46
posts/2017/2017-02-24-termux-pour-quoi-faire.md Executable file
View file

@ -0,0 +1,46 @@
<!-- title: Termux pour quoi faire ? -->
<!-- categories: GNU/Linux Mobilité -->
<!-- tag: planet -->
Cascador m'a communiqué son engouement pour [Termux](https://termux.com) à
travers sa série d'articles [Termux sur
Android](https://www.blog-libre.org/serie/termux-sur-android).<!-- more --> En quelques
mots, Termux est un terminal pour Android qui émule un environnement Debian et
permet d'installer certains programmes à travers le gestionnaire de paquets
**apt**. Point intéressant, cela fonctionne sans avoir *rooté* son appareil
Android et le projet est plutôt actif avec des mises à jour de paquets
régulières. La série de Cascador décrit différents scénarios d'utilisation :
installer un serveur SSH, utiliser des outils console, accéder à des API
Android.
<img src="/images/2017/termux-esynic.jpg" alt="termux" style="margin: 0px 20px;
float:left;" />J'ai bien mordu, jusqu'à me faire offrir un super clavier
bluetooth pour Noël (merci frérot).
Le risque était que le coup de coeur retombe ; qu'après avoir
bien rigolé à installer **vim** et consorts, on s'essoufle à cause des
limitations techniques (on n'a pas un vrai Linux, le matériel a des
performances limitées) ou du manque d'utilité. Et bien, après 3 mois
d'utilisation, je peux témoigner que ce n'est pas mon cas. J'ai deux cas
d'usages récurrents (en plus de faire le malin) sur ma tablette.
Premier usage : j'ai un Linux dans la poche (enfin dans le sac à dos) qui me
permet d'accéder à mes serveurs hébergés. Termux va plus loin qu'un simple
client SSH car je peux rapatrier et transférer des fichiers, j'ai des outils de
base de Linux (curl, wget). La tablette est Wifi et je peux monter un Hotspot
Wifi avec mon téléphone donc je peux faire le pompier de n'importe où.
Seconde utilisation : j'ai installé tout ce qu'il faut pour écrire mes articles
de blog. C'était un peu prédestiné à vrai dire : ayant un blog statique dans
lequel j'écris mes articles en
[Markdown](https://daringfireball.net/projects/markdown), j'ai besoin d'outils
*console* uniquement : **vim** pour écrire et **python** pour générer le blog
en HTML. Du coup en local je peux écrire et vérifier ma production. Et avec une
connexion Internet, je publie l'article grâce à **git**.
Termux est une application publiée sur le Play Store et sur F-Droid, sous
licence GPL, qui vaut le coup d'être testée. Et en fonction de vos besoin, vous
pourriez bien y trouver un intérêt sur le long terme.

101
posts/2017/2017-02-27-gnu-systemlinuxd-gnomeos.md Executable file
View file

@ -0,0 +1,101 @@
<!-- title: De GNU/Linux à gnuSystemlinuxdGnomeOs -->
<!-- categories: GNU/Linux BSD Humeur -->
Cet article n'est pas un réquisitoire contre **systemd** mais l'argumentaire de
mon positionnement<!-- more --> qui me situe quelque part entre les deux positions
régulièrement entendues :
- systemd c'est tout pourri, la preuve regardez ce bug
- systemd c'est le progrès inévitable et en plus ça ne change rien pour l'utilisateur final
J'ai vécu en première ligne l'arrivée de systemd dans nos distributions et,
professionnellement, l'impact a été la nouvelle manière de décrire des
services. C'est simple et standard entre les distributions qui ont basculé sur
systemd soit presque l'intégralité des distributions *mainstream* en 5 ans :
Redhat / Centos / Fedora bien sûr puisque le projet est dirigé par Lennart
Poettering, un employé de Redhat, Ubuntu et... Debian qui a dérogé à sa ligne
de conduite d'intégrer des outils mâtures et stables et a misé sur systemd,
probablement trop tôt, et s'est mis en conflit avec une partie de ses
contributeurs qui ont pris la porte et démarré le projet
[Devuan](https://devuan.org/fr/). Je ne vais pas m'étendre car c'est polémique
mais il y a une pression de l'équipe systemd, depuis sa création, pour forcer
son adoption rapide par les distributions ce qui a fortement contribué à son
image de [boatware](https://fr.wikipedia.org/wiki/Bloatware) truffé de bugs.
Bon ok, mais c'est quoi le but de systemd ? Au début, je pensais que ça se
cantonnait à un nouveau système d'init plus rapide et standardisé. Après des
discussions avec mon double Linuxien à moustache et diverses lectures il
ressort que plus rapide (car systemd est parallèlisé) est un argument léger :
sur un serveur on s'en cogne, et les 1% d'utilisateurs de Linux Desktop ne
verront aucune différence avec un SSD à 30 balles. Par contre, ce parallélisme
cause un manque de prédictabilité de l'ordre de démarrage et pose des problèmes
aux gens qui font de l'embarqué avec Linux (et là on ne parle pas de 1%
d'utilisateurs mais du gigantesque marché de l'IoT et du M2M).
Bon, mais alors c'est quoi le but de systemd ? Il semble que ce soit la
fourniture d'API pour faire papa / maman afin que l'environnement de bureau
Gnome sur lequel à misé Redhat puisse devenir plus qu'un simple environnement
de bureau mais une expérience utilisateur disruptive par une intégration
poussée avec son système d'exploitation (pensez à un pingouin qui court sur une
banquise en train de se réchauffer). Bref, Gnome veut devenir le nouveau
MacOS/X pour atteindre... 2% du marché des PC de bureau... à une époque où le
PC ne se vend plus. Bon j'ironise mais je comprends l'objectif de l'équipe
Gnome qui a envie de passer à la vitesse supérieure et qui est le seul DE en
position de le faire aujourd'hui. Donc cette élaboration d'une API standard
entre les distributions serait la justification aux modules engrangés par
systemd: gérer les points de montage, remplacer CRON, résoudre le DNS [avec
brio](https://www.blog-libre.org/2017/04/20/essuyer-les-platres-dns-sur-ubuntu).
En tirant une ligne vers l'horizon et en fermant un oeil, on voit la finalité :
Linux, Systemd, Wayland, Gnome => un Linux Desktop OS avec un niveau de
finition et une accessibilité au même niveau qu'un Mac OS/X, un Windows 10 ou
un Android. Avec le soutien de Redhat, je ne doute pas qu'ils vont réussir :
systemd va se stabiliser et se fiabiliser. Pour quel marché, c'est moins
clair...
Ce qui me gêne, moi, c'est la mise en terre de la philosophie UNIX. Ca ne
semble pas parler beaucoup aux utilisateurs enthousiastes (ou résignés) de
systemd. C'est peut-être une différence de culture ou de génération. La planète
linuxienne est enthousiaste sur son système, beaucoup sont même concernés par
la liberté à travers les licenses. Moi j'ai connu UNIX avant de connaître
Linux. J'ai adoré les cours de mon vieux professeur en salopette qui les mains
dans les poches nous faisait revivre la naissance d'Internet à travers les
différents protocoles basés sur TCP/IP et le fonctionnement interne d'un
système UNIX. J'ai connu les UNIX propriétaires (Solaris, HP/UX, AIX) et j'ai
adoré sa philosophie :
- KISS : Keep It Simple Stupid
- un outil => une tâche
- des mécanismes éprouvés pour faire travailler ces outils ensembles (comme les |)
- le format texte privilégié en toute circonstance sur le binaire
Quand Linux est arrivé, j'ai bien sûr apprécié de pouvoir installer un UNIX sur
un PC personnel mais c'est aussi le GNU et la GPL qui m'ont séduit, la notion
de partage et de retour des contributions à la communauté. J'admire le noyau
Linux pour ce qu'il est devenu en l'espace de 20 ans, en terme de performance,
de fiabilité et de support du matériel. Mais c'est juste un kernel ; ce qui
compte aussi énormément c'est la GPL et la philosophie UNIX du système complet.
Systemd est une anti-thèse à la philosophie UNIX : un init binaire, des logs
binaires, une construction théoriquement modulaire mais avec tellement de
dépendances qu'il s'impose comme indispensable, une réinvention de la roue en
permanence. Il est plausible que systemd s'invite dans le kernel Linux dans
quelque temps. Et le résultat sera sûrement appétissant à l'oeil pour le Linux
de bureau et il simplifiera la vie de certains administrateurs systèmes. Ceux qui
envient leurs collègues certifiés Microsoft apprécieront même.
Mais Linux ne sera plus un système UNIX... Et si je veux utiliser un UNIX-Like
j'ai Android, et bientôt Windows 10 vu la vitesse du rapprochement de Microsoft
avec Canonical.
Donc si je veux utiliser un système UNIX, il me reste :
- les BSD qui, paradoxalement, alors qu'ils sont issus des UNIX propriétaires, apparaîssent aujourd'hui comme les dépositaires de la foi (euh philosophie)
- quelques rares distributions GNU/Linux qui aiment UNIX (comme Gentoo ou Slackware par exemple). Non ce n'est pas de la vaine résistance. Linux ce n'est pas juste un kernel et des programmes GNU. Il y a autre chose à préserver.
J'ai donc décidé de n'utiliser plus que des systèmes qui respectent ces
critères. Ca n'empêchera pas la terre de tourner et *gnuSystemlinuxdGnomeOs* de
voir le jour et occuper sa place mais, comme pour le 7 mai prochain, c'est à
chacun de se positionner en son âme et conscience.
Moi j'ai choisi UNIX.

20
posts/2017/2017-06-05-lavie-lamour-lesvaches.md Executable file
View file

@ -0,0 +1,20 @@
<!-- title: La vie, l'amour, les vaches -->
<!-- category: Humeur -->
<!-- tag: planet -->
C'est une année de recentrage, dans la lignée de 2016, où la vie numérique
prend un peu moins de place.<!-- more --> Ce n'est pas planifié, c'est arrivé un peu comme
ça, un peu provoqué par les événements : deux changements professionnels en 6
mois, beaucoup de réflexion sur la vie, des week-ends plus orientés *bricolage*
que geekerie... c'est peut-être un effet de bord de la quarantaine, ce qui m'a
inspiré le titre de cet article, en référence au film avec Billy Crystal de
1991.
Bref, je continue à suivre l'actualité "Admin sys" par hobby et l'actualité du
développement par passion pour mon métier. Je suis l'actualité Linux en
filigrane, je m'arrête souvent au titre pour les articles du style "la distrib
Zorglub, fork de (Debian|Ubuntu) est sortie". Je préfère de loin les articles
sur l'auto-hebergement, la protection de la vie privée ou le DIY et je lis tout
ce que je trouve sur BSD.
![la vie, l'amour, les vaches](/images/2017/lesvaches.jpg "la vie, l'amour, les vaches")

66
posts/2017/2017-06-18-sublime-vs-atom.md Executable file
View file

@ -0,0 +1,66 @@
<!-- title: Sublime Text vs Atom -->
<!-- category: Développement -->
<!-- tag: planet -->
Je suis un utilisateur intermédiaire de VIM. Je connais les commandes de base
et certaines plus avancées, j'utilise quelques plug-ins<!-- more --> et je suis friand des
articles du style *"10 tips for VIM power users"*. J'installe Vim sur tous mes
systèmes et c'est mon éditeur favori en mode console, généralement pour des
connexions distantes SSH sur des serveurs. Pour progresser plus, et *level-up
comme disent les jeunes*, il faudrait pratiquer quotidiennement et l'utiliser
comme IDE, ce qu'il peut être pour les langages du Web et beaucoup d'autres.
Mais je ne suis pas aussi engagé et j'aime bien utiliser un éditeur de texte
avancé plus classique (comprenez avec pilotage à la souris, des onglets et une
barre de menu), en complément de Eclipse, mon IDE pour Java. Depuis quelques
années, cet éditeur c'est [Sublime Text](https://www.sublimetext.com) dans sa
version 3 et je n'ai rien à redire. Sublime est élégant, performant et il a
amené des fonctionnalités puissantes, qu'on peut retrouver dans VIM avec les
bons plugins, mais dans un éditeur graphique et convivial : l'extensibilité des
fonctions (plug-ins), des thèmes, la minimap sur la droite de l'éditeur, la
fonction *goto anything*.
Ceci dit, je regarde ce qui sort regulièrement, et depuis 2 ans, je teste
régulièrement [Atom](https://atom.io), l'éditeur conçu par GitHub. Ce qui me
plait dans Atom, c'est que l'équipe GitHub a développé l'outil pour le
développement dont ils avaient besoin, en s'inspirant du meilleur de ce qui
existe (et beaucoup de Sublime) tout en essayant de faire mieux. Présenté comme
un *Hackable Editor* c'est sur ce terrain qu'il montre sa grande force, son
extensibilité. Mon test de la mouture du moment, montre des nets progrès de la
stabilité et des performances.
Caractéristques de **Sublime Text** :
- développé par Jon Skinner, licence propriétaire
- multiplateforme : Ms Win, Mac OS/X, Linux
- code natif C++ et Python
- extensions en Python, fédérées par Will Bond sur [Package Control](https://packagecontrol.io)
- +4000 paquets : la plupart sous licences open source
- versioning : création 2008, sublime 2 puis Sublime 3, officiellement en bêta *stable* depuis janvier 2013
- prix : autour de 70$
Caractéristiques d'**Atom** :
- développé par GitHub, licence MIT
- multiplateforme : Ms Win, Mac OS/X, Linux
- plateforme Web Electron (basée sur Chromium et NodeJS)
- codé en CoffeScript, un langage qui se transcompile en JavaScript
- étendu par des plug-ins en Node.js et ouverture JavaScript vers C++ pour s'interfacer avec des produits tiers
- +6000 paquets : la plupart sous licences open source
- versioning : création 2014, v 1.17.2
L'empreinte mémoire est à l'avantage de Sublime, moins de -100 Mo au démarrage.
Atom ne peut pas rivaliser sur ce plan avec son architecture Web basée sur
Electron. Si votre utilisation consiste à charger des fichiers de dizaines de
milliers de lignes (épluchage de logs par exemple), choisissez Sublime ou Vim
car Atom sera lent. Par contre, si vous cherchez un éditeur multi-langages pour
écrire du Python, du Ruby, du JavaScript, du CSS, de l'HTML, Atom est une
alternative sérieuse. Son éco-système grossit très vite : +6000 plug-ins. Basé
sur Electron, il est *Web* lui-même et on peut exécuter / déboguer du
JavaScript depuis l'éditeur.
En conclusion, Sublime est plus généraliste et plus performant pour gérer des
fichiers volumineux. Atom est plus versatile et la croissance du nombre de
plug-ins montre l'engouement des développeurs Web. J'ai une licence Sublime
mais j'ai fait la bascule sur Atom depuis quelques semaines pour tout ce qui
est développement (JAVA mis à part).

103
posts/2017/2017-06-21-openbsd-installation.md Executable file
View file

@ -0,0 +1,103 @@
<!-- title: Deux installations de OpenBSD -->
<!-- categories: Hébergement BSD -->
Déjà un peu évoqué sur Diaspora, j'ai migré mon serveur vers OpenBSD depuis
deux mois<!-- more --> à une période où les planètes étaient alignées : j'avais du temps et
l'envie, et aussi une revanche à prendre suite à une installation ratée l'année
dernière sur mon portable. Les BSD m'intriguaient depuis longtemps, plus
spécialement OpenBSD et j'avais commencé à regarder et apprécier la qualité de
la documentation et j'avais l'image d'une petite communauté qui prend le temps
de réfléchir, de bien faire les choses sans céder aux sirènes de la mode, en
maintenant un cap : la sécurité avant tout et le KISS. Ce qui me retenait
hormis la difficulté apparente, c'était mon goût pour la GPL. Les mois ont
passé, la tournure qu'a pris Linux a commencé à me déplaire. Puis Thuban a
publié la première version de son livre sur l'auto-hébergement avec OpenBSD et
il a montré que non seulement ce n'etait pas si compliqué mais qu'on pouvait
faire tourner tous les services de l'auto hébergement. C'est un point très
important car venant d'une distribution Linux comme Debian avec ses milliers de
programmes, on peut craindre qu'OpenBSD soit pauvre et qu'il faille tout se
compiler à la mimine. En fait, la vérité est ailleurs, pardon à mi chemin :
pour une utilisation serveur, on trouve tout ce qu'il faut pour de
l'hébergement de services et plus en standard (*out of the box*) que certaines
distributions Linux pour l'administration système.
Ça a ravivé la flamme et migrer mon serveur vers OpenBSD c'etait concret en
terme d'objectif. J'héberge un certain nombre de services : lecteur de flux RSS
(Tiny Tiny RSS), gestionnaire de favoris (Shaarli), partage de fichier,
synchronisation d'agenda et de carnet d'adresse (NextCloud), lecture hors ligne
(Wallabag) et ce blog (Pelican / Stacosys). Des services classiques mais sur un
nouveau système avec des programmes différents et une administration
différente. Ma cible c'est donc [ma Dedibox chez
Online](https://www.online.net/fr/serveur-dedie/dedibox-sc) pour laquelle
OpenBSD n'est pas encore officiellement supporté mais FreeBSD est proposé, ce
qui augure du bon concernant le support du matériel. En cherchant un peu sur la
toile, quelques courageux aguerris avaient déjà expérimenté et [partagé une
méthode d'installation
manuelle](https://devnullblg.wordpress.com/2014/04/18/openbsd-installation-on-a-dedibox-sc-gen2).
Je me suis donc lancé, muni :
- des [pages man](http://man.openbsd.org/cgi-bin/man.cgi) : sur OpenBSD c'est
beaucoup plus que de simples pages man ; très détaillées, agrémentées
d'exemples, c'est l'essentiel de la documentation officielle.
- du livre [Héberger son serveur avec OpenBSD](https://www.atramenta.net/books/heberger-son-serveur-avec-openbsd/562)
- de quelques retours d'expérience sur le Net.
- [du Wiki OBSD4](https://obsd4a.net/wiki)
J'ai pris mon temps pour me familiariser avec les programmes développés par
OpenBSD. C'était le principal intérêt : ne pas juste réinstaller un serveur Web
et PHP mais apprendre le système et ses programmes particuliers : le pare-feu
(pf), le serveur HTTP (httpd), le load-balancer applicatif (relayd). Sur
quelques jours, j'ai remonté un serveur avec tous mes services, sécurisé et
simpliste d'administration. Ça tourne depuis 2 mois et à part un oeil au
rapport de sécurité quotidien envoyé par le serveur dans ma boite e-mail et aux
bulletins de sécurité publiés par l'équipe OpenBSD, je n'ai plus rien fait.
C'est le week-end dernier que j'ai réalisé que les connaissances acquises
risquaient de se perdre par manque de pratique. Et puis je suis loin de tout
maîtriser, j'etais reste au chapitre de la théorie sur les mises à jour de
sécurité par exemple. Or j'ai maintenant un serveur OpenBSD en production...
Ma solution : pratiquer plus régulièrement donc installer OpenBSD sur mon
vénérable Toshiba portege (année 2009, core 2 duo, 4go de ram, ssd de 64 Go,
écran 13''3) et conserver mon vieux portable Ldlc (année 2011, i7, 8go ram, 750
Go hdd, écran 15''6) sous Linux. Et c'est ainsi que j'ai retenté l'installation
sur le fameux Toshiba. Le plus gros écueil avec BSD c'est le support du
matériel, moins vaste que sur Linux.
Le toshi est un bon candidat avec ses composants tout Intel (carte graphique,
chipset Wi-Fi). Et pourtant les problèmes ont commencé dès l'installation avec
un gel du boot depuis la clef USB à cause de l'acpi, un standard pas toujours
correctement implémenté par les constructeurs et où la rigueur d'OpenBSD a été
bloquante. Après desactivation temporaire de l'acpi depuis le UKC (User Kernel
Configuration) j'ai pu mener l'installation jusqu'au bout.
Le démarrage se passe bien, le système est fonctionnel mais je n'ai pas de
réseau. Un message au boot suggère que le firmware du chipset n'est pas
disponible. En effet, aucun code propriétaire n'est embarqué dans OpenBSD.
Depuis un autre PC, j'ai téléchargé [le firmware
nécessaire](http://firmware.openbsd.org/firmware/6.1) et je l'ai installé avec
[fw_update](http://man.openbsd.org/fw_update.1). J'ai du wifi après c'est de la
configuration : l'installation de xfce (il paraît que mate est pour bientôt),
mes outils habituels (Vim, Tmux, Firefox, Thunderbird).
Dernier écueil, j'ai planté pendant l'installation de XFCE avec *pkg_add* car
le PC chauffe pas mal, à cause de son âge. Sur Linux, j'utilise des outils
comme *cpufreq* pour limiter la fréquence du processeur. J'ai cherché un
équivalent un petit moment avant de m'apercevoir que c'est en standard dans
OpenBSD et qu'il suffit de configurer le Kernel avec des directives comme
[hw.setperf par sysctl](http://man.openbsd.org/sysctl.8). Le planté en pleine
installation de paquets a corrompu la référence de pkg. Je ne pouvais plus
terminer l'installation, le système voyait des incohérences entre ce qui était
déjà installé et sa base de référence. J'ai regénéré sa référence en combinant
les outils **pkg_check** et **pkg_delete**. Ca m'a mis en confiance sur la
robustesse du système de gestion de paquets. A cette étape, j'ai un laptop sous
OpenBSD avec XFCE.
J'ai enchaîné sur les patchs de mise à jour de sécurité du kernel avec
**syspatch**, un outil récent qui permet d'appliquer des patchs binaires et de
regénérer un nouveau kernel. Je me suis rassuré en appliquant les patchs
publiés depuis la sortie de OpenBSD 6.1 sur le portable pour valider la
manipulation puis j'ai fait de même sur le serveur.
J'utilise indifféremment mes deux portables selon les jours donc je devrais
alterner régulièrement entre Linux et OpenBSD et suivre l'évolution de ces deux
mondes parallèles, à la fois très proches et très différents.

68
posts/2017/2017-07-12-migration-hugo.md Executable file
View file

@ -0,0 +1,68 @@
<!-- title: Migration du blog sous Hugo -->
<!-- category: Blog -->
<!-- tag: planet -->
J'ai remplacé le le moteur de blog statique Pélican par Hugo et à vrai dire, ce
n'était pas prévu.<!-- more --> Un peu cloué par le rhume pour le week-end, j'ai suivi la
recommandation du médecin de rester tranquille. La cervelle fonctionnant encore
un peu, j'ai consulté ma liste de projets pour l'année, vous savez cette liste
mi-voeux / mi-résolutions qu'on établit en début d'année. En bonne place,
j'avais noté *"apprentissage ou perfectionnement dans un langage informatique"*.
Les années précédentes, j'ai fait un peu de Javascript, notamment [un prototype
de MVC avec MEAN](https://github.com/kianby/sandbox), de la glue Web à droite à
gauche mais j'ai toujours l'impression de partir de zéro avec ce langage.
Pourtant Javascript est de plus en plus incontournable professionnellement, même
pour un développeur plutôt teinté backend. Mais pour bien progresser il aurait
fallu partir avec un objectif projet, pas des exemples.
Au lieu de ça, j'ai flâné sur Rust et Go, des langages bas niveau (rien de
péjoratif). Cela fait un moment que je lorgne sur Go et franchement ce qui me
retient c'est le fait que ce soit porté par Google. J'ai un peu en travers leur
habitude de balancer les projets quand ils n'en ont plus besoin ou leurs
ruptures sans compatibilité ascendante (hein Angular). Bref j'hésite à
m'investir... Mais il faut reconnaître que Go est sorti en 2007, ils l'utilisent
vraiment en interne (pas comme Angular) et ça me plairait de rajouter un langage
plus bas niveau que Java ou Python avec des performances supérieures à mon
catalogue. A force de traîner sur des sites qui parlent du langage Go je suis
tombé sur Hugo, un moteur de blog statique. J'ai trouvé la documentation très
bien écrite et c'est un point de plus en plus important pour moi. J'ai décidé de
l'essayer... juste pour voir.
Je ne vais pas refaire pas la pub du blog statique. Démarré sur la plate-forme
Blogger, j'ai successivement migré ce blog sous Wordpress, PluXml, puis Pélican
et je ne reviendrai pas en arrière. D'un blog statique avec des articles écrit
en Markdown il est aisé de migrer vers n'importe où et on maîtrise le code HTML
généré (celui de Wordpress était particulièrement dégueulasse). En pratique ça
m'a pris une heure pour écrire une moulinette qui a transformé mes articles au
format de Hugo, c'est-à-dire qui a transformé les metadata de chaque article, le
contenu restant [au format
Markdown](https://daringfireball.net/projects/markdown).
Ce qui m'a pris du temps c'est le thème. J'ai testé quelques thèmes de
contributeurs, beaucoup lu la documentation détaillant la création de son propre
thème et je me suis lancé en transposant mon thème de Pélican (enfin les parties
HTML CSS) en mieux : avec les parties spécifiques paramétrables, dans un esprit
de réutilisation et de partage (oui c'est beau) même si ça n'arrivera
probablement jamais car mon thème est.. moche mais beau pour moi, amélioré,
raffiné au fil des ans, allégé avec [Pure CSS](https://purecss.io). Si je devais
changer un truc ce serait ajouter un peu couleur sur la bannière de haut de
page, ça ferait moins de gris. Quand le thème a été achevé on aurait dit une
copie du blog original mais qui se **génère en 1/2 seconde au lieu de 5
secondes**, la rapidité du langage Go compilé est réelle. J'ai retravaillé les
catégories et utilise intelligemment les tags pour générer des flux RSS
spécifiques notamment celui du [Planet Libre](http://planet-libre.org). Le
résultat est propre, exempt des années de bidouilles et de verrues que j'avais
ajouté sur Pélican.
J'ai un peu tâtonné pour générer exactement les mêmes URL puis j'ai abandonné.
J'ai préféré ajouter l'année dans l'URL d'un article, adieu mon référéncement
Google et mes millions de lecteurs désorientés ;-) Pour limiter la casse, j'ai
rajouté une règle au niveau du serveur HTTP pour rediriger les erreurs 404 vers
la page d'accueil.
Dernière angoisse, est-ce que le langage Go allait être disponible sur OpenBSD ?
La réponse est oui, et encore mieux, le projet Hugo fournit un binaire pour
OpenBSD. La mise en place sur l'hébergement a été galette. Quant au [système de
gestion des commentaires](https://github.com/kianby/stacosys) il est à nouveau
opérationnel (c'est l'avantage de maîtriser sa stack de logiciels) mais ça m'a
donné un peu de fil à retordre... Cela fera le sujet d'un prochain article.

158
posts/2017/2017-07-16-performance-python-web.md Executable file
View file

@ -0,0 +1,158 @@
<!-- title: Performance Python Web -->
<!-- categories: Développement Hébergement Blog -->
J'ai terminé l'article précédent en évoquant le [système de gestion des
commentaires Stacosys](https://github.com/kianby/stacosys) et sa mise en place
sur le blog propulsé par [Hugo](https://gohugo.io).<!-- more --> Il est installé sur le même
serveur que le blog mais il pourrait tout à fait être déporté car le blog
statique interagit avec lui par du code JavaScript qui envoit des requêtes
RESTful afin de :
- récupérer le nombre de commentaires d'un article
- récupérer les commentaires d'un article
- soumettre un nouveau commentaire
Avant de migrer vers Hugo, les commentaires étaient visibles seulement à
l'intérieur des articles. C'est à dire qu'une page de blog affiche un extrait de
l'article, à raison de 10 articles par page, et une pagination (page précédente /
page suivante) permet de naviguer. C'est seulement quand on lit un article
particulier qu'en fin de page on a un bouton *"voir les XX commentaires"* qui
affiche le nombre de commentaires de l'article. Donc en navigation, on n'a
aucune requête vers Stacosys. C'était un choix technique pour ne pas le
surcharger de requête. En réécrivant le thème, j'ai trouvé sympa d'ajouter
l'affichage du nombre de commentaires de chaque article sur la page principale,
ce qui se fait un peu de partout.
Cela ressemble à ceci :
![Nombre de commentaires sur la page](/images/2017/page-comments.png)
La récupération du nombre de commentaires des 10 articles de la page est
réalisée en JavaScript donc de manière asynchrone et on envoie 10 requêtes vers
le serveur HTTP de Stacosys qui est celui du framework Python Flask. J'ai voulu
tester un peu les limites du système pour avoir une idée de ce le blog est
capable de supporter.
Le test consiste à effectuer le plus de requêtes possible pendant 1 minute avec
une charge de 250 clients simultanés par seconde. Avec 10 articles par page,
cela correspond à 25 lecteurs simultanés et particulièrement excités qui tapent
frénétiquement sur la touche F5 pour rafraichir la page du navigateur donc
beaucoup plus de lecteurs avec un comportement *normal*. Sur une base de 8
secondes de visite par page, cela correspond à 200 visiteurs simultanés. J'en
suis loin, c'est mon nombre de visites par jour :-) mais cela donne un objectif
de charge à tenir.
Quand la minute est écoulée on regarde **combien de requêtes** on a pu
satisfaire et **le temps de réponse moyen** pour les satisfaire. La qualité du
résultat dépend de ces deux variables. J'ai fixé arbitrairement 10 secondes
comme temps de traitement acceptable. Les requêtes non honorées dans ce laps de
temps sont marquées en erreurs. N'ayant pas 250 volontaires, j'ai utilisé une
plate-forme de test non libre (oui je sais
[Richard](https://fr.wikipedia.org/wiki/Richard_Stallman)...)
Comment lire le tableau des résultats :
- La colonne *workers* indique le nombre de processus ou threads travaillant en
parallèle pour traiter les requêtes.
- Le temps de réponse est en millisecondes avec le temps minimum, le temps moyen et le temps maximum.
- Les erreurs sont des timeout : la requête n'a pas pu être honorée en moins de 10 secondes.
J'ai d'abord fait un test dans l'état actuel avec Stacosys en HTTPS et le
résultat est assez décevant. Pour le test, j'ai repassé Stacosys en HTTP et le
résultat m'a étonné :
| Serveur | Workers | Temps de réponse | Requêtes | Erreurs |
| ----------- | :-----: | :----------------: | -------: | ------: |
| Flask HTTP | 1 | 95 > 2595 > 20000 | 7169 | 197 |
| Flask HTTPS | 1 | 104 > 4194 > 32000 | 4043 | 326 |
On constate un écroulement complet en HTTPS. Je sais qu'il y a un coût, mais la
gestion SSL étant portée par le serveur HTTP en frontal, je n'aurais pas pensé à
une telle baisse de performance.
Comme on récupère un nombre de commentaires par article, une information non
critique, j'ai envisagé de demander cette information en HTTP. Ca n'aurait pas été
glorieux mais la différence de performance est telle que je l'ai envisagé avec
deux options qui ne peuvent pas fonctionner.
**Option 1** : le blog reste en HTTPS et fait des appels CORS en HTTP à Stacosys.
Ce n'est pas autorisé par les navigateurs car on n'a pas le droit de baisser la sécurité.
**Option 2** : le blog revient en HTTP, après tout ce ne sont que des articles et il
appelle Stacosys tantôt en HTTP, tantôt en HTTPS, en fonction de la criticité de
l'information. On posterait les commentaires en HTTPS mais on fournirait le
nombre de commentaires par article en HTTP. Et bien c'est impossible aussi car
avec une configuration SSL un peu sérieuse, le paramètre
[HSTS](https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security) est activé
pour éviter les attaques du type
[man-in-the-middle](https://fr.wikipedia.org/wiki/Attaque_de_l%27homme_du_milieu)
et, dans mon cas, j'ai fixé la durée HSTS à 1 année. Donc si je désactive HTTPS,
les navigateurs de mes lecteurs continueront à se connecter en HTTPS, à moins de
purger leur paramétrage. N'ayant pas les numéros de téléphone de tout le monde,
c'est foiré. C'est à garder en mémoire pour ceux qui envisageraient de passer à
HTTPS avec Let's Encrypt pour voir... Le retour en arrière n'est pas évident si
HSTS est en place.
Donc il va falloir vivre avec HTTPS et essayer d'améliorer les performances !
![Speedy](/images/2017/speedy.png)
Il est vrai que le serveur HTTP de Flask est préconisé pour le développement et
pas la production. On recommande d'utiliser [Gunicorn](http://gunicorn.org) ou
[Uswgi](https://uwsgi-docs.readthedocs.io/en/latest) qui sont optimisés (avec
des parties écrites en langage C ou C++), fournissent de la concurrence dans le
traitement. J'ai testé Uswgi qui m'a donné beaucoup de fil à retordre par sa
complexité de configuration. J'ai fait un test un peu meilleur mais avec une
charge CPU beaucoup plus lourde. Il faut trouver un équilibre entre le gain de
performances Web et l'impact sur la charge CPU du serveur en rajoutant des
processus *workers*.
Ces deux serveurs Web sont probablement très bien et tout le monde semble les
utiliser pour la mise en production d'application Python Web sérieuses mais pour
mon besoin plus humble, ça me gêne de modifier l'application à cause du
déploiement. Alors à force de chercher j'ai déniché une alternative qui
s'appelle [Sanic](http://sanic.readthedocs.io) : un serveur HTTP en pur Python
qui utilise les capacités de traitement asynchrones de Python 3.5 ce qui lui
permet avec 1 worker, de doubler les performances de Flask. Remplacer Flask par
Sanic dans une application Flask c'est galette : les développeurs de Sanic ont
défini une API très proche, pensée pour que la migration se fasse rapidement.
Voici les résultats de Sanic avec différentes configurations de *workers* :
| Serveur | Workers | Temps de réponse | Requêtes | Erreurs |
| ----------- |:-------:|:------------------:| --------:| -------:|
| Flask HTTPS | 1 | 104 > 4194 > 32000 | 4043 | 326 |
| Sanic HTTPS | 1 | 85 > 2657 > 20023 | 8741 | 123 |
| Sanic HTTPS | 2 | 85 > 2087 > 23634 | 7048 | 198 |
| Sanic HTTPS | 4 | 86 > 1777 > 18936 | 8102 | 191 |
On constate que le nombre de requête traités grimpe et que le temps de réponse
moyen s'améliore. Par contre, le nombre d'erreur augmente un peu. La performance
HTTP progresse car le serveur est capable de gérer plus de requêtes mais le
temps de traitement ne progresse pas et il faut toujours effectuer une requête
dans la base de données pour renvoyer le nombre de commentaires. Pire, cette
partie requête en base n'est pas asychrone donc on bloque un *worker*. Pour la
1ère page du blog qui est la plus consultée, ce sont les mêmes compteurs qui
sont demandés par chaque visiteur. Il y a un réel intérêt à mettre en cache ces
valeurs pour diminuer le temps de traitement. C'est ce que j'ai fait
programmatiquement dans Stacosys avant de relancer un test de performance avec
le cache activé.
| Serveur | Workers | Temps de réponse | Requêtes | Erreurs |
| ------------------- |:-------:|:------------------:| --------:| -------:|
| Flask HTTPS | 1 | 104 > 4194 > 32000 | 4043 | 326 |
| Sanic HTTPS | 4 | 86 > 1777 > 18936 | 8102 | 191 |
| Sanic HTTPS + cache | 4 | 81 > 1152 > 12408 | 13558 | 210 |
| Sanic HTTPS + cache | 1 | 81 > 1367 > 18869 | 11589 | 171 |
On traite plus de requêtes en moins de temps, le gain est palpable. Le cache est
pour beaucoup dans le gain et pour le dernier test je suis revenu à 1 worker
seulement pour limiter la charge CPU du serveur. Le résultat est honorable avec
plus de 11000 requêtes traitées et un taux d'erreur assez bas. C'est cette
configuration que j'ai mis en place sur le blog.
Après avoir rédigé cet article, j'ai effectué un test basique (pas dans le
contexte Stacosys) avec le serveur HTTP du langage Golang et le résultat m'a
ramené à mes lectures du moment sur les architectures microservices, les couches
protocolaires optimisées comme [nanomsg](http://nanomsg.org) et les langages
compilés. Il n'est pas exclu que je réécrive mes outils différemment.

38
posts/2017/2017-07-20-flux-rss-esprit-du-libre.md Executable file
View file

@ -0,0 +1,38 @@
<!-- title: Flux RSS et esprit libre -->
<!-- categories: Blog Humeur -->
J'ai réalisé que mon flux RSS est tronqué depuis [ma migration sous
Hugo](/2017/migration-du-blog-sous-hugo) et je viens de corriger le tir.<!-- more --> Loin de moi
l'idée de forcer les gens à venir sur le blog pour lire l'article en entier et
ainsi gonfler mes statistiques (ridiculement basses) ou flatter mon égo. Mea
culpa auprès du [Planet Libre](http://www.planet-libre.org) aussi d'avoir fourni
un article tronqué.
En cherchant des informations pour définir mon flux RSS correctement je suis
tombé sur le blog d'un anglophone, appelons le Jim, qui dénonce le choix du
développeur de Hugo d'avoir insidieusement glissé le passage d'un flux complet à
un flux partiel au détour d'une version, sous le fallacieux argument que c'est
ce que veulent la plupart des utilisateurs. Pour remettre le problème en
perspective, on n'est impacté que si on n'a pas défini son propre modèle de
document RSS pour son site, auquel cas c'est le modèle par défaut fourni par
Hugo qui est utilisé ; et c'est ce modèle qui a changé entre deux versions. En
lisant la doc de Hugo on est capable de définir son propre modèle RSS en 10
minutes.
En parcourant le blog de Jim, on lit qu'il a récemment quitté Pélican pour Hugo
et qu'il est assez remonté que le développeur du projet fasse des choix pareils
et qu'il compte migrer son blog vers Wordpress. Deux jours plus tard, il pond un
nouvel article incendiaire pour informer ~~que Wordpress ne fonctionne pas en
IPv6~~ qu'il ne comprend rien. Jim est prolifique ; il pond plusieurs articles
par semaine et il a des idées sur tout. Enfin comme dirait Coluche il a surtout
des idées.
Alors voici quelques rappels et conseils à tous les Jim de la planète :
- utiliser un projet libre ou open source ne donne pas de droit privilégié envers la gouvernance du projet. Les développeurs du projets ne travaillent pas pour toi en fait et ils risquent même de mener le projet selon leurs envies.
- l'investissement minimal que tu te dois en tant qu'utilisateur, pour éviter les surprises, c'est de te tenir au courant des sorties de version et de leur contenu (le fameux *changelog*).
- l'investissement plus coûteux en temps consiste à suivre les discussions sur les orientations, voire à participer pour influer sur l'evolution du projet : la plupart des projets ont un forum ou un espace de discussion.
- et si rien ne te convient tu peux toujours prendre un clavier, apprendre la programmation si nécessaire, et démarrer toi même le projet qui convient à ton besoin. Tu ne le meneras probablement pas à terme mais tu auras appris beaucoup de choses et ça t'aura peut-être rendu plus humble et respectueux du travail des autres.
- tu peux aussi choisir des projet commerciaux (open source ou privateurs) qui te donneront accès à du support et au droit de râler car tu es un client.
Voilà Jim, la balle est dans ton camp :-)

172
posts/2017/2017-07-24-golang-a-la-rescousse.md Executable file
View file

@ -0,0 +1,172 @@
<!-- title: Performances, Golang à la rescousse -->
<!-- categories: Développement Blog -->
<!-- tag: planet -->
Dans l'[article précédent](/2017/performance-python-web) j'ai optimisé le
[système de gestion des commentaires
Stacosys](https://github.com/kianby/stacosys)<!-- more --> en :
- remplaçant le serveur HTTP de [Flask](http://flask.pocoo.org) par [Sanic](http://sanic.readthedocs.io), un serveur HTTP Python tirant parti des capacités asynchrones de Python 3.5 et multi-processus (plusieurs *workers*)
- ajoutant un cache mémoire à la partie de l'API de Stacosys qui récupère le compteur de commentaires d'un article
J'ai terminé sur une performance bien améliorée :
- plus de 11000 requêtes traitées en 1 minute
- un temps de requête moyen de 1,3 seconde
- une répartition du temps de traitement entre 81 ms et 18 secondes (assez élevé)
- 171 des requêtes (soit 1,5 %) avec un temps de traitement supérieur à 10 secondes
L'architecture avec Sanic ressemble à ceci :
![Architecture Stacosys cache](/images/2017/diag-sanic-cache.png)
Pour être complet le serveur HTTPS NginX en frontal de Stacosys est configuré
avec 4 *workers* et il déverse les requêtes sur Sanic configuré avec 2
*workers*, qui lui seul utilise 30% de la CPU lors du test. L'impact sur la CPU
est important et doit être mis en balance avec le gain en performance car
d'autres services tournent sur le même serveur.
[NginX](https://fr.wikipedia.org/wiki/Nginx) est un serveur Web très complet et
il y a des configurations avancées de mise en cache qui, d'après sa
documentation, pourraient s'appliquer à mon scénario : un serveur HTTP en mode
Proxy qui renvoie au format JSON les résultats d'une API. Si c'est le cas, cela
rendrait caduque la nécessité d'ajouter un cache au niveau du serveur HTTP de
Stacosys. J'ai fait quelques essais et je ne suis pas arrivé à un résultat
fonctionnel. Si vous avez des retours d'expérience, j'aurais voulu mesurer les
performances de cette solution. Logiquement, elle devrait l'emporter sur les
autres.
Je cherchais depuis un petit moment une ~~occasion~~ excuse pour écrire un peu
de Golang. Un test HTTP (hors contexte) de Golang m'a convaincu que je pourrais
m'en servir. Le langage [Golang](https://golang.org) a la particularité d'être
compilé, typé, multi-plateforme et il fournit en standard des fonctionalités de
haut niveau comme HTTP (client et serveur), de la crypto et de la compression,
le support du JSON. [Le débat reste
ouvert](http://spf13.com/post/is-go-object-oriented) sur le fait que Golang soit
un langage orienté objet. En tout cas, il propose un paradigme de programmation
simple et une richesse de librairies qui le rendent très intéressant pour du
développement généraliste où la performance compte.
J'ai donc restauré Stacosys en situation initiale (retour au serveur HTTP de Flask)
et j'ai ajouté un serveur HTTP avec cache en Golang qui sert de proxy à NginX pour
récupérer le compteur de commentaires. Les autres appels à l'API de Stacosys sont
envoyés directement à Stacosys.
L'architecture devient ainsi :
![Architecture Golang HTTP/Cache](/images/2017/diag-go-http.png)
Dans cette configuration, j'ai relancé mon fameux test étalon. On éclate tout
avec + de 14000 requêtes traitées, un taux d'erreur équivalent mais surtout un
temps de réponse moyen divisé par 4 et une charge CPU d'à peine 7%. Le serveur
HTTP est mono-processus mais il utilise à fond les capacitéss des goroutines de
Golang pour gérer la concurrence de traitement.
| Serveur | Workers | Temps de réponse | Requêtes | Erreurs |
| ------------------- |:-------:|:------------------:| --------:| -------:|
| Flask HTTPS | 1 | 104 > 4194 > 32000 | 4043 | 326 |
| Sanic HTTPS + cache | 4 | 81 > 1152 > 12408 | 13558 | 210 |
| Sanic HTTPS + cache | 1 | 81 > 1367 > 18869 | 11589 | 171 |
| Golang HTTPS | ? | 80 > 341 > 6745 | 14663 | 175 |
Pour les fans de code, voici celui du serveur HTTP avec cache :
``` golang
package main
import (
"encoding/json"
"flag"
"fmt"
"github.com/patrickmn/go-cache"
"io/ioutil"
"net/http"
"os"
"time"
)
// ConfigType represents config info
type ConfigType struct {
HostPort string
Stacosys string
CorsOrigin string
}
var config ConfigType
var countCache = cache.New(5*time.Minute, 10*time.Minute)
func die(format string, v ...interface{}) {
fmt.Fprintln(os.Stderr, fmt.Sprintf(format, v...))
os.Exit(1)
}
func commentsCount(w http.ResponseWriter, r *http.Request) {
// only GET method is supported
if r.Method != "GET" {
http.NotFound(w, r)
return
}
// set header
w.Header().Add("Content-Type", "application/json")
w.Header().Add("Access-Control-Allow-Origin", config.CorsOrigin)
// get cached value
cachedBody, found := countCache.Get(r.URL.String())
if found {
//fmt.Printf("return cached value")
w.Write([]byte(cachedBody.(string)))
return
}
// relay request to stacosys
response, err := http.Get(config.Stacosys + r.URL.String())
if err != nil {
http.NotFound(w, r)
return
}
defer response.Body.Close()
body, err := ioutil.ReadAll(response.Body)
if err != nil {
http.NotFound(w, r)
return
}
// cache body and return response
countCache.Set(r.URL.String(), string(body), cache.DefaultExpiration)
w.Write(body)
}
func main() {
pathname := flag.String("config", "", "config pathname")
flag.Parse()
if *pathname == "" {
die("%s --config <pathname>", os.Args[0])
}
// read config File
file, e := ioutil.ReadFile(*pathname)
if e != nil {
die("File error: %v", e)
}
json.Unmarshal(file, &config)
fmt.Printf("config: %s\n", string(file))
http.HandleFunc("/comments/count", commentsCount)
http.ListenAndServe(config.HostPort, nil)
}
```
La démonstration ne vise pas à conclure qu'il faut tout réécrire en Golang car
Python est trop lent !
Hier, je lisais un article à propos de [Discord](https://discordapp.com/), une
application concurrente de Teamspeak avec de la VoIP, des gros besoins de
concurrence de traitement (5 millions de messages échangés en permanence), du
Web et de l'application mobile. Leur solution mixe 4 langages différents :
Python, NodeJS, Golang et Elixir (Erlang) ; chacun a son rôle et son champ
d'application dédié. Plus on acquiert une culture large de l'informatique et
plus on sera capable de choisir le bon langage / paradigme de
programmation / framework en fonction de la tâche à accomplir, ce qui rejoint ce
dicton anglo-saxon que j'aime bien même s'il est un peu galvaudé : *if all
you have is a hammer, everything looks like a nail*.

52
posts/2017/2017-08-09--email-important.md Executable file
View file

@ -0,0 +1,52 @@
<!-- title: L'e-mail n'a jamais été aussi important -->
<!-- category: Humeur -->
<!-- tag: planet -->
En lisant les réactions enflammées des utilisateurs de OpenMailBox qui ont, à
juste titre, l'impression d'avoir été pris pour des jambons, on réalise que cet
e-mail, dont on annonce régulièrement la mort prochaine mais sans avoir de
remplaçant, est encore plus important qu'auparavant.<!-- more -->
Pour beaucoup de la nouvelle génération, c'est un moyen de communication dépassé
et ils ont tendance à créer des e-mails en pagaille pour s'inscrire sur des
sites mais pas spécialement pour communiquer. Cela change rapidement à
l'approche de l'entrée dans le monde du travail et la nécessité d'avoir un
e-mail stable, qui ne soit pas *kikou48*, afin d'envoyer des CV à des recruteurs.
L'adresse e-mail représente **une identité** par :
- sa composition : utiliser le classique prenom.nom ou bien inventer un jeu de mot mnemotechnique avec son nom ou son prénom
- le choix de son domaine : le choix d'un GAFAM (gmail, yahoo, outlook) ou un domaine à soi (qu'on vous fera souvent répéter car c'est rare)
Avec la généralisation de l'e-mail comme identifiant pour s'inscrire à n'importe
quel site ou forum, **la pérennité** de l'e-mail est devenue vitale. Quelques
années plus tôt, on envoyait un e-mail aux personnes de son carnet d'adresse
avec sa nouvelle adresse et c'était bon. Aujourd'hui on est inscrit sur quantité
de sites et un changement est long, pénible et peut tourner à la galère si vous
n'avez plus accès à la boite de votre ancienne adresse.
Cela conforte l'idée de ne pas confier son e-mail à des fournisseurs
(commerciaux ou associatifs) qui ne seront pas capables de garantir cette
pérennité. Ca fait mal de l'écrire, mais il est aujourd'hui plus pérenne de
confier son e-mail à un GAFAM qu'à une startup qui joue la carte de la
protection de la vie privée et peut changer ses conditions de services ou
déposer le bilan.
Néanmoins, ce n'est pas ce que je recommande car :
- l'e-mail GAFAM est pérenne mais il n'est pas sécurisé. Clairement on échange un service contre sa vie privée qui sera scrutée et modélisée à des fins de profilage.
- l'e-mail GAFAM peut être clôturé sur un malentendu et sans recours possible ; on a vu des précédents.
Avec la déclaration obligatoire des impôts sur le revenu en ligne à partir de
2018, la situation ne vas pas s'arranger. Une partie de la population (je pense
aux seniors notamment mais pas seulement) qui n'est peut-être pas initiée à l'informatique va
devoir déclarer en ligne et fournir un e-mail de contact qui sera son principal
lien avec l'administration. Est-ce qu'on a prévu de former ces gens ? Est-ce
qu'il y a un plan national de fournir un e-mail *à la française*, sécurisé,
pérenne dans le temps ou bien va-t-on les donner en patûre aux GAFAM ?
C'est une question semi-ouverte, je ne suis pas très confiant de l'issue :-(
Aujourd'hui ceux qui protègent leur vie privée ont été sensibilisés au problème
et ils ont une culture de base en informatique. Cela laisse encore du monde sur
le bas-côté de la route.

163
posts/2017/2017-09-04-nextcloud-securite.md Executable file
View file

@ -0,0 +1,163 @@
<!-- title: Sécurité des données, focus sur Nextcloud -->
<!-- categories: Hébergement BSD -->
<!-- tag: planet -->
En 2007, j'ai ouvert un compte Dropbox avec l'offre gratuite de 2 Go. J'avais
parrainé des collègues et des amis pour gagner de l'espace de stockage. Oui je
le reconnais, j'avais vendu des amis au
[GAFAM](https://fr.wikipedia.org/wiki/GAFAM) contre quelques octets<!-- more --> : mes
~~parrainages~~ compromissions m'avaient permis d'atteindre 6 Go de stockage...
Vertigineux ;-) A cette époque, ma fibre libriste était encore latente, j'étais
fier d'avoir autant d'espace et je m'en servais pour partager des photos avec la
famille. Je ne me suis jamais senti assez en confiance pour partager des
documents importants.
En 2010, j'ai commencé à héberger mes services et en 2014 je démarrais avec
[Owncloud](https://owncloud.org) principalement pour la synchronisation des
contacts et du calendrier. Puis j'ai commencé à partager quelques fichiers, mais
rien d'important. En 2015, j'ai remplacé Owncloud par [Cozy](https://cozy.io),
de la fameuse startup française qui oeuvre pour que l'utilisateur reprenne le
contrôle de sa vie numérique et ne la brade plus aux GAFAM. Cozy va plus loin
que le partage de fichiers et c'est vraiment un projet à suivre de près. C'est
avec eux que j'ai commencé à prendre confiance et partager des documents
importants. Et en 2016, je suis revenu vers Owncloud ou plus exactement vers son
fork né des guéguerres internes : [Nextcloud](https://nextcloud.com).
Bref mon compte Dropbox ne me servait plus depuis un bail mais j'avais du mal à
décider sa fermeture... mince c'était quand même gratuit ;-) Aujourd'hui il est
officiellement clôturé.
Donc j'ai quelques Giga octets de données sur Nextcloud, notamment des documents
administratifs, et je suis responsable de la sécurité de mes données. Alors la
sécurité c'est un vaste sujet. Cela commence par une protection physique des
données. Si mon serveur était à la maison, j'aurais probablement chiffré le
disque dur en cas de vol. Là il est chez un fournisseur de confiance, dans un
datacenter sécurisé donc l'accès direct à mon disque dur est le moins probable.
![Mr Robot dans le data center](/images/2017/mrrobothack.jpg)
La pierre angulaire de la sécurité c'est le système d'exploitation et ses
capacités intrinsèques à résister aux attaques. Ensuite c'est de la
configuration : le parefeu, le routage réseau, la virtualisation, des outils de
détection d'attaques qui vont permettre d'améliorer la sécurité du système. Mais
si le système d'exploitation est gâté à la base, tout ce qui suit est un
emplâtre sur une jambe de bois ! Enfin on se comprend :-)
![Tux et BSD grillent XP](/images/2017/tux-bsd-windows.jpg)
Depuis quelques mois, mon serveur est propulsé par OpenBSD (et je ne suis pas
prêt de revenir en arrière). Avec de la lecture et des conseils, je l'ai
sécurisé du mieux que j'ai pu. Je n'entrerai pas dans les détails, je ne suis
pas assez qualifié pour donner des cours sur le sujet mais le résultat n'est pas
mal du tout.
Pour la sécurité de mes données, ce qui m'inquiète le plus ce sont les failles
potentielles des applications hébergées qui pourraient servir de porte d'entrée
royale pour accéder aux données. La parano venant, j'ai décidé d'attaquer le
sujet par étapes et aujourd'hui j'ai focalisé sur mon instance **Nextcloud**.
C'est une application Web avec son propre sous-domaine qui donne directement sur
ce bel écran de connexion :
![Nextcloud login](/images/2017/nextcloud-login.png)
J'accède à mes données en mobilité donc il n'est pas possible de restreindre
l'accès par adresse IP. Donc je suis dépendant du système d'authentification de
Nextcloud. Première étape, je dois savoir ce qui se passe. Nextcloud fournit un
rapport d'audit et on peut configurer les actions qui doivent y figurer.
![Nextcloud audit](/images/2017/nextcloud-audit.png)
C'est une fonction nécessaire mais pas suffisante. Le rapport est envoyé chaque
heure si des données ont changé, un peu tard si on s'est fait ~~ni~~ha-cker.
Exemple de rapport :
Bonjour,
Vous recevez cet email car l'activité suivante a eu lieu sur https://nextcloud.mondomaine.fr/
* Vous avez partagé Partage/Blog/documents avec un lien public - Aujourd’hui 16:54:04
* Partage/Blog/documents/moderncv.zip téléchargé par lien public - Aujourd’hui 16:54:48
* Vous avez créé Notes/todo.txt - Aujourd’hui 17:04:49
Ce que j'aimerais aussi avoir, c'est un moyen de bloquer les gars qui font du
[brute-force](https://fr.wikipedia.org/wiki/Attaque_par_force_brute) sur l'écran
de connexion pour trouver mon mot de passe. C'est faisable si l'application a la
bonne idée de noter dans un log quand une tentative de connexion échoue :
- Sous Linux, l'excellent outil fail2ban (ben oui c'est du Python) permet d'analyser un
log à la recherche de messages spécifiques, d'extraire l'adresse IP concernée et
de créer une règle de blocage dans le parefeu (iptables) pour une durée
déterminée.
- Sous OpenBSD, Thuban s'est inspiré de fail2ban pour créer [Vilain](https://yeuxdelibad.net/Blog/?d=2017/02/05/09/53/19-vilain-setoffe) qui
fonctionne de concert avec l'incroyable parefeu [pf](https://man.openbsd.org/pf.conf).
Ce qui suit est donc réalisé avec Vilain sous OpenBSD mais c'est facilement transposable sous Linux.
Je bloque les fâcheux pendant une heure avec cette règle pour Vilain qui
fonctionne aussi bien pour l'écran de connexion à l'interface Web que pour
l'accès aux fichiers avec WebDAV.
[nextcloud]
logfile = /var/www/htdocs/datacloud/nextcloud.log
regex = .*Bruteforce attempt from \\"(.*)\\" detected
Quid des partages par lien public ? En effet, Nextcloud permet aussi de partager
un fichier ou un dossier à quelqu'un qui n'a pas de compte avec un lien public.
La création d'un partage est aussi simple que ceci :
![Nextcloud partage](/images/2017/nextcloud-partage.png)
La sécurité repose essentiellement sur l'URL générée *au hasard* donc le partage
d'un document important sans spécifier de mot de passe est à proscrire.
D'ailleurs l'interface d'administration de Nextcloud permet d'interdire la
création de tels liens par les utilisateurs. J'utilise assez souvent ces liens
publics et je ne m'étais jamais posé la question de leur sécurité. Alors
mauvaise nouvelle, si on crée un lien avec mot de passe et que l'URL tombe dans
les mains d'un malfaisant (ou réussit à être devinée), il peut tranquillement
faire du brute-force sur le lien car Nextcloud n'écrit aucune info dans ses logs
sur ces erreurs d'authentification. Pas cool ça hein <i class="fa fa-ambulance" aria-hidden="true"></i>
La solution va venir du logs d'accès du serveur HTTP qui trace toutes les
requêtes HTTP et leur code retour. Pour un accès avec le bon mot de passe,
on aura un log comme celui-ci :
80.214.223.96 - - [02/Sep/2017:12:36:58 +0200] "POST /s/wKDvKK8vt6ZSU5E/authenticate HTTP/1.1" 303 5 "-" "Mozilla/5.0 (BB10; Kbd) AppleWebKit/537.35+ (KHTML, like Gecko) Version/10.3.3.2163 Mobile Safari/537.35+"
Alors que pour un accès refusé car le mot de passe est incorrect on aura ceci :
80.214.223.96 - - [02/Sep/2017:12:36:27 +0200] "POST /s/wKDvKK8vt6ZSU5E/authenticate HTTP/1.1" 200 16186 "-" "Mozilla/5.0 (BB10; Kbd) AppleWebKit/537.35+ (KHTML, like Gecko) Version/10.3.3.2163 Mobile Safari/537.35+"
Alors au premier abord, ça semble bizarre car l'erreur de mot de passe renvoie
un code HTTP 200 qui correspond à OK. C'est parce qu'en cas d'erreur, on reste
sur la page qui redemande le mot de passe, alors qu'en cas de succès le code de
retour est une redirection HTTP 303 vers la page qui affiche les documents du
partage. Le formatage de mes logs d'accès dépend de la configuration de mon
serveur HTTP (en l'occurence NginX) donc l'expression régulière qui permet
d'identifier les erreurs de mot de passe doit en tenir compte. Sur cette base je
peux rajouter la règle suivante à Vilain :
[nextcloud-share]
logfile = /var/www/logs/access-nextcloud.log
regex = (\d+\.\d+\.\d+\.\d+) \-.*POST /s/\w+/authenticate HTTP/1.1\" 200
Voilà, nous avons deux règles efficaces qui vont bloquer les attaquants à chaque
double échec d'authentification. C'est cool mais je voudrais aussi connaître le
nombre de mes ennemis, car si je suis soumis à des centaines d'attaques par jour
je réviserai peut-être ma façon de me protéger. Je vais donc m'envoyer un rapport
journalier de l'activité de Vilain :
- je modifie la configuration de Vilain pour qu'il écrive dans un log dédié et non plus dans */var/log/daemon*
- je configure un recyclage journalier pour ce log à minuit
- j'ajoute une tâche CRON à minuit moins 2 brouettes pour m'envoyer par e-mail le log de la journée
Quelque chose comme ça :
# /etc/newsyslog.conf
/var/log/vilain 640 5 * $D0 Z "rcctl restart vilain"
# crontab
55 23 * * * cat /var/log/vilain | mail -s "Vilain Rapport" yax
Oui je l'ai appelé le **Vilain Rapport**, au niveau de l'humour on ne se refait pas :-)

148
posts/2017/2017-10-01-protegeons-vie-privee.md Executable file
View file

@ -0,0 +1,148 @@
<!-- title: Protégeons notre vie privée -->
<!-- category: Humeur -->
<!-- tag: planet -->
Framasoft [fête les 3
ans](https://framablog.org/2017/09/25/degooglisons-internet-cest-la-fin-du-debut)
de sa campagne [Dégooglisons Internet](https://degooglisons-internet.org). Le
nombre de services alternatifs aux GAFAM, libres et respectueux de la vie
privée, a grossi ainsi que le nombre d'utilisateurs.<!-- more --> Comme ils l'expliquent
eux-mêmes, le but n'est pas de devenir un hébergeur professionnel mais plutôt de
servir de catalyseur pour que les gens prennent conscience qu'il y a une autre
voie, décident de se libérer et auto-hébergent leurs services s'ils le peuvent
ou aient recours au tissu associatif à travers [le collectif des
Chatons](https://chatons.org) par exemple.
Chaque fin d'année je fais un don financier à un ou deux acteurs qui me semblent
cruciaux dans le monde du Libre ; c'est d'ailleurs généralement la période de
relance, chacun essayant de boucler son budget de fonctionnement pour l'année à
venir. Beaucoup ont besoin d'aide et ils sont à la fois nos bras armés et nos
boucliers. Je pense à Framasoft, à la Quadrature du Net, à l'APRIL, à Wikipedia, à
des équipes de développement, des distributions Linux. Bref il y a beaucoup à
soutenir et il faut faire des choix. Cette année je serais exclusif et ce sera
Framasoft pour rétribuer mon usage de [Framasphere](https://framasphere.org) et
soutenir la suite de la campagne.
Pour ma part, j'ai dégooglisé progressivement depuis un bout de temps les
services vitaux : contacts, agenda, mails. Ca ne veut pas dire qu'on peut
m'appeler [Richard](https://fr.wikipedia.org/wiki/Richard_Stallman) et que je
n'utilise aucun service GAFAM :
- j'utilise Youtube, mais je n'ai pas envie qu'on me profile à travers mes recherches,
- la navigation Waze me sort régulièrement des soucis à Marseille,
- j'ai un compte Twitter pour participer à des concours et suivre quelques stars du Net (comme [Korben](https://korben.info) que je lis depuis des années et apprécie pour sa constance et sa franchise)
Comme en religion, chacun met la barre à son niveau et voit jusqu'où il veut /
peut aller... et on trouve aussi des extrémistes dans ce domaine.
Donc en plus d'ordinateurs sous Linux et OpenBSD, d'un téléphone génial utilisé
par 0,1% du marché, j'ai aussi une belle tablette Android déjà évoquée dans mes
articles autour de [Termux](https://termux.com) : bootloader verrouillé, ROM
Android du constructeur. Je surfe avec Firefox, j'utilise mes propres services
pour le mail, l'agenda, les contacts, le cloud. Mais je suis quand même sur un
système non maîtrisé qui :
- me propose tous les jours des mises à jour d'applications que je n'utilise pas : Gmail et consorts,
- m'a imposé une mise à jour Android qui a cassé la possibilité de me connecter au hotspot Wi-Fi de mon télphone donc adieu Internet quand je suis en vadrouille,
- rame de plus en plus, sans que je trouve d'explication, jusqu'à rendre la tablette inutilisable plusieurs minutes à chaque sortie de veille Wi-Fi,
- mange certains jours 1/4 de batterie alors qu'il est censé être en veille.
Bref, la coupe était pleine. La garantie de la tablette étant expirée, je me
suis décide à regarder ce qui est faisable : idéalement changer la ROM, à défaut
revenir à une version précédente du constructeur. Je passe les détails
techniques affligeants mais parti sur l'option 2, j'ai failli transformer la
tablette en brique et j'en suis sorti à force de parcourir le forum XDA à la
recherche d'infos. Pour les connaisseurs j'étais bloqué au BIOS dans l'EFI (car
oui ma tablette a un processeur Intel) et j'ai réussi à réinjecter ma ROM
d'origine (celle du constructeur) avec une manipulation tordue. Ce que j'ai
retenu c'est que monde Android c'est le monde Ms Windows tel que je lai quitté
il y a des années : la plupart des gens sur les forums ne connaissent pas grand
chose et préconisent d'appliquer des recettes de cuisine : installe tel soft,
fais telle manip. Ce n'est pas leur faute, on est sur un sytème fermé (pour ce
qui est du bootloader en tout cas) donc à part quelques initiés qui ont la
connaissance acquise par la sueur à force de *reverse-engineering*, la masse ne
fait que propager de l'information erronée et recopier des topics de forums.
Revenu donc au point de départ, j'ai tenté le *rootage* de la tablette ; c'est
moins risqué qu'un changement de ROM. Je l'ai réalisé et j'ai pu désinstaller
les applications Google de ma tablette gràce à un utilitaire nommé **/system/app
mover** trouvé sur le magasin d'applications [F-Droid](https://f-droid.org).
J'ai commencé petit, en virant les applications Google, puis j'ai carrément viré
le Playstore et surtout ses services. J'ai récupéré 300 Mo de mémoire (pas
négligeable sur une tablette de 2 Go) et je n'ai plus aucun ralentissement
depuis 3 semaines. Je me suis prouvé, au passage, que toutes les applications
dont j'ai besoin pour ma tablette sont sur F-Droid.
![Tablette](/images/2017/tablette-root.jpg)
Est-ce que c'est parfait ? Non pas du tout car j'ai enlevé les applications
Google et quelques services du système, mais je ne maîtrise pas ce qui reste :
il peut rester un service de pistage qui bouffe mes données et les envoie à
Google.
Une dégooglisation complète passe par plusieurs étapes :
1. se libérer des services GAFAM et mettre en place soi-même ou utiliser des alternatives.
2. utiliser un système d'exploitation libre ou *de confiance* :
- un système GNU/Linux (pas n'importe lequel) ou un système BSD
- en mobilité, sur Android :
- *rooter* l'appareil pour pouvoir faire le ménage, c'est mieux que rien.
- installer une ROM commmunautaire (pas n'importe laquelle) sans les Google Apps, c'est mieux.
3. utiliser du matériel libre grâce à l'Open Hardware
Je considérais, jusqu'à récemment, le 3ème point exagéré pour des équipements
domestiques mais j'ai largement changé d'avis.
Le ciblage publicitaire est de plus en plus précis. Ma moitié a reçu dans la
semaine un e-mail d'encouragement pour s'inscrire sur le site de la Française
des Jeux, probablement car elle est passée sur leur site pour consulter les
résultats. Elle navigue sur un Samsung A5 avec Chrome donc qu'ils aient obtenu
l'e-mail ne m'étonne pas, mais qu'ils connaissent mon prénom un peu plus. En bas
de l'e-mail, [la société tierce responsable de ce
profilage](http://www.eperflex.com/lg/fr/fonctionnalites) propose de se
désabonner de leurs services. J'aime me désabonner quand je n'ai jamais été
invité à m'abonner... Bref ma moitié navigue essentiellement en 4G donc cela
exclut le recoupement avec notre adresse IP domestique. Je penche plutôt pour un
recoupement entre son e-mail et d'autres données glanées à droite à gauche (???)
pour parvenir à lier nos identités.
La semaine d'avant nous avons été confrontés, toujours sur le Samsung, au
mini-scandale de l'enregistrement des visages, une sympathique fonctionnalité,
[découverte par Seb Sauvage](http://sebsauvage.net/links/?0vFdFg), destinée à
enrichir la base de reconnaissance faciale de Google. [Dans son dernier
article](http://standblog.org/blog/post/2017/09/29/Payer-son-smartphone-avec-ses-donn%C3%A9es-personnelles),
Tristan Nitot clarifie bien ce *deal* entre Google et les constructeurs de
téléphone.
Pour les appareils mobiles, le matériel est bien le souci principal. Et on peut
se demander jusqu'à quand certains constructeurs pourront continuer à fournir
des bootloader déverrouillés pour faire plaisir à quelques clients, sans que
Google durcisse sa position et l'interdise. De plus, installer une ROM
communautaire résoud partiellement le problème : il reste des bouts de code
propriétaires dans les composants électroniques du téléphone dont on ne connait
pas le fonctionnement. La solution ultime est un téléphone **Libre de A à Z** :
logiciel (Open Source / Libre) et matériel (Open Hardware).
On a assisté une succession de projets de téléphones plus ou moins libres depuis
quelques années : [OpenMoko](https://fr.wikipedia.org/wiki/OpenMoko),
[Maemo](https://fr.wikipedia.org/wiki/Maemo) et plus récemment, FirefoxOS et
Ubuntu Phone.
Ne nous voilons pas la face, ils ont tous échoué, mais ils ont apporté leur
pierre à l'édifice et participé à la prise de conscience du problème des GAFAM
et du marchandage de notre vie privée qui dépasse largement le cercle des geeks
aujourd'hui.
Le ~~buzz du moment~~ prochain téléphone libre serait [le
Librem](https://puri.sm/). Encore faut-il y croire suffisamment et avoir
confiance dans la société Purism pour mettre la main à la poche et subventionner
sa création.
En tout cas, avoir pris conscience du problème c'est déjà un grand pas et le
début de l'action pour reprendre sa vie numérique en main.
La route est longue mais la voie est libre !
![Phagocitage](/images/2017/phone-boss.jpg)
Source de l'image : [maymay](https://framasphere.org/people/f01a0d1e920196e5)

98
posts/2017/2017-10-14-attrapons-les-vilains.md Executable file
View file

@ -0,0 +1,98 @@
<!-- title: Attrapons les vilains -->
<!-- categories: Hébergement BSD -->
A la fin de [mon article sur le blocage des attaques de brute
force](/2017/nextcloud-securite/), j'étais resté sur l'envoi quotidien d'un
e-mail avec le log des attaques de la journée, histoire d'avoir une idée de ce
qui s'est passé.<!-- more --> Pour rappel, mon serveur tourne sous OpenBSD et l'outil de
protection contre les attaques est Vilain, un équivalent de Fail2ban sous Linux.
Le log de la journée est fastidieux à lire et j'ai eu envie de construire un
rapport avec les informations suivantes :
- liste des adresses IP bloquées
- répartition horaire des attaques
- top des adresses IP les plus agressives
Après un échange avec [Thuban](http://yeuxdelibad.net), le créateur de Vilain,
nous convenons que Vilain doit rester
[KISS](https://fr.wikipedia.org/wiki/Principe_KISS), qu'il n'est pas souhaitable
de compliquer son code pour générer un rapport. Il est préférable de réaliser le
travail en externe en analysant les logs. C'est ainsi que j'ai écrit
**vilainreport** (une centaine de lignes en Python), qu'on peut lancer
quotidiennement avec une tâche CRON pour recevoir le rapport du jour :
cat /var/log/vilain | vilainreport | mail -s "Vilain rapport du jour" admin
**vilainreport** est intégré au [dépôt de Vilain sur Framagit](https://framagit.org/Thuban/vilain).
Voici un exemple de rapport généré par *vilainreport*:
### Date 2017-10-12
00:17:00 blacklist IP 156.196.136.52 (ssh)
01:26:17 blacklist IP 115.249.139.206 (ssh)
02:31:08 blacklist IP 218.62.64.179 (ssh)
02:35:16 blacklist IP 91.223.167.69 (ssh)
02:46:54 blacklist IP 27.102.203.180 (ssh)
...
Probe 'ssh' : 137 attacks
### Attacks per probe
Probe 'ssh': 137 attacks
### Hourly repartition
Hour 00 - 01: 1
Hour 01 - 02: 1
Hour 02 - 03: 4
Hour 03 - 04: 4
...
### Top attackers
IP 195.184.191.147 : 6
IP 81.4.110.104 : 5
IP 90.63.248.112 : 5
IP 176.31.126.176 : 5
...
Ma configuration personnelle de Vilain est la suivante : je bannis pendant 1
heure toute adresse après sa deuxième tentative erronée de connexion à un de mes
services. Donc un *Top attacker* qui a été banni 6 fois dans la même journée n'a
pas fait d'erreur de connexion. Il a vraiment l'intention de s'introduire dans
mon serveur. Je pourrais durcir ma configuration pour bannir beaucoup plus d'une
heure mais ça ne m'arrange pas car je partage des documents avec des gens qui
peuvent se tromper une fois ou deux en saisissant leurs identifiants Nextcloud.
J'ai donc décidé de mettre en place une sanction plus dure pour les récidivistes :
les jeter dans un puits sans fond, concrètement, une blackliste définitive au
niveau du pare-feu OpenBSD.
![Prison de Bane](/images/2017/darkknight-prison.jpg)
J'ai appliqué une logique similaire à *vilainreport*. Je réinjecte le rapport
dans un petit shell script **supervilain** qui identifie les récidivistes et les
jette dans le puits, où il resteront... jusqu'au prochain redémarrage du serveur.
Voici le script en Korn Shell :
``` shell
#!/bin/ksh
if [ $# != 1 ]; then
echo "Usage: $0 logfile"
exit 1
fi
file=${1--}
while read line
do
line=`echo $line | tr -d '\r'`
if [[ $line = IP* ]]; then
ipend="${line##+(IP )}"
ip="${ipend%%+( ):*}"
count="${ipend##*\: }"
if [ "$count" -gt "2" ]; then
echo "Ban supervilain ${ip} (${count})"
`pfctl -t supervilain -T add ${ip}`
fi
fi
done <"$file"
```

121
posts/2017/2017-11-17-un-blog-plus-statique.md Executable file
View file

@ -0,0 +1,121 @@
<!-- title: Un blog plus statique -->
<!-- categories: Hébergement Blog -->
<!-- tag: planet -->
Un échange avec [Bruno Adelé](http://bruno.adele.im), qui fut l'initiateur du
projet CaCause à une époque (déjà 5 ans) où les blogs statiques n'avaient pas
d'autre alternative que Disqus, a titillé mon intellect.<!-- more --> Bruno envisage de
migrer son blog vers [Hugo](https://gohugo.io) et d'utiliser le gestionnaire
de commentaires [staticman](https://staticman.net) dont la particularité est
de soumettre les commentaires par des pull-request GIT.
Cela m'a rappelé [le projet Pecosys](https://blogduyax.madyanne.fr/2014
/pecosys-les-commentaires-avec-pelican) qui avait une approche similaire : les
commentaires étaient partie intégrante du blog, publiés dans GIT sous forme de
fichiers au format Markdown et convertis en HTML par le moteur de blog
Pelican. La complexité de mise en oeuvre de Pecosys (un dépôt GIT privé, un
e-mail dédié, un plugin spécifique pour Pelican) ont eu raison du projet. Deux
ans plus tard, je codais Stacosys en simplifiant un peu les pré-requis
système. Entre temps, des alternatives crédibles à Disqus avaient vu le jour
comme [Isso](https://posativ.org/isso) notamment. Stacosys est donc resté un
projet personnel et depuis, il gère les commentaires de ce blog.
Dans Stacosys, les commentaires ne font plus partie des sources du blog. le
navigateur Web du lecteur communique directement avec Stacosys via une API
REST et une instance de Stacosys peut être partagée entre plusieurs sites par
[des requêtes CORS](https://fr.wikipedia.org/wiki/Cross-
origin_resource_sharing). Stacosys stocke les commentaires dans sa base de
données et il ne fait plus de GIT. Contrairement à Pecosys (PElican COmment
SYStem), Stacosys n'est pas lié à un moteur de blog particulier, il est
facilement intégrable dans une page HTML par un peu de JavaScript.
![Architecture actuelle Stacosys](/images/2017/schema-stacosys-avant.jpg)
Au vu de mon utilisation mono-site de Stacosys je me suis demandé si je ne
pourrais pas revenir à une génération des commentaires en pages statiques.
Cela apporte plusieurs avantages :
- une plus grande rapidité de navigation : au lieu d'ajouter les commentaires à la page en asynchrone par JavaScript, ils font partie de la page
- la capacité à supporter plus d'utilisateurs simultanés car le serveur HTTP ne sert que des ressources statiques
- plus de sécurité sur mon serveur grâce une surface d'attaque réduite : plus besoin d'une application HTTP REST accessible sur Internet
L'idée n'est pas réécrire Stacosys mais de pouvoir l'utiliser dans les deux cas
de figure : mono-site et multi-site.
Le moteur de blog Hugo fournit une solution technique élégante à travers [les
data templates](https://gohugo.io/templates/data-templates). Il s'agit de
récupérer de l'information pendant la construction du blog pour enrichir les
pages avec une information dynamique (qui peut changer à chaque build). On
peut lire des fichiers JSON sur disque, ou mieux, faire des requêtes HTTP pour
récupérer du JSON.
Ca tombe bien, Stacosys fournit une API REST qui renvoie du JSON :-) Ni une ni
deux, j'ai adapté mes modèles pour que Hugo interroge Stacosys pendant sa
phase de build et génère les articles en incluant les commentaires en fin de
page.
Voici le *template* Hugo des commentaires qui utilise la fonction **getJSON** pour récupérer les commentaires
de la page en cours :
``` html
{% raw %}
<div id="stacosys-comments">
{{ $restParam := (printf "/comments?token=%v&url=%v" .Site.Params.widgets.stacosys_token .URL) }}
{{ $resp := getJSON .Site.Params.widgets.stacosys_url $restParam }}
{{ range $resp.data }}
<hr>
<div class="inline">
{{ if isset . "site" }}
<a href="{{ .site }}">
{{ end }}
<img src="http://www.gravatar.com/avatar/{{ .avatar }}.jpg" style="float:left; margin-right:10px" height="32" width="32">
{{ if isset . "site" }}
</a>
{{ end }}
<span class="title">{{ .author }}</span>
<span> - {{ .date }}</span>
</div>
<p>
{{ .content | markdownify }}
</p>
{{ end }}
</div>
{% endraw %}
```
et un exemple de données renvoyée par Stacosys :
``` json
{% raw %}
{
"data": [
{
"author": "Bruno",
"avatar": "b97a3605714350fdad083394c974a9b4",
"content": "Ça donne effectivement envie de se laisser convaincre par un Librem. Le seul problème c'est que c'est déjà limite si j'ai un téléphone mobile et payer un tel prix alors que je pourrais pratiquement avoir un nouvel ordinateur au même montant, ça ne donne pas trop envie. Quand mon téléphone actuel cessera de fonctionner, peut-être que je choisirai plutôt de ne pas en racheter.",
"date": "2017-10-01 20:03:46"
},
{
"author": "Yax",
"avatar": "308a3596152a79231f3feedc49afa4ef",
"content": "Je comprends c'est pas mon budget téléphone non plus. Une alternative acceptable c'est le reconditionné de téléphones éprouvés et connus pour être bien supportés par les ROMs communautaires. Ça fait un peu d'écologie en prime.",
"date": "2017-10-01 22:20:37"
}
]
}
{% endraw %}
```
Il reste une interaction entre le serveur HTTP et Stacosys pour poster des
commentaires via le formulaire mais on n'a plus besoin que Stacosys ait son nom
FQDN propre et soit exposé sur Internet.
Le nouveau système ressemble à ceci :
![Nouvelle architecture Stacosys](/images/2017/schema-stacosys-apres.jpg)
Les sources complets sont sur [mon Github](https://github.com/kianby).
C'est en place depuis le début de la semaine et je suis ravi du résultat.
Combiné avec un Firefox Quantum pour la navigation ça roxe du poney !

83
posts/2017/2017-12-14-kif-microservices.md Executable file
View file

@ -0,0 +1,83 @@
<!-- title: Mon kif pour les microservices -->
<!-- category: Développement -->
<!-- tag: planet -->
Je m'intéresse aux microservices depuis un bout de temps. Comme pour beaucoup
de sujets de fond, je suis à maturation lente : j'engrange les concepts, je
lis les retours d'expérience, je pèse les avantages et les inconvénients.<!-- more -->
Quand on a commencé à parler d'architecture microservices, l'engouement était
tel qu'on confrontait souvent l'architecture orientés services (SOA) et on
présentait les microservices comme la réponse adéquate pour tout type
d'application. Aujourd'hui, les esprits sont plus calmes, l'opinion commune
décrit l'architecture à base de microservices comme une version plus
granulaire que le SOA, qui suit les mêmes principes (séparation des
responsabilités, interface de communication formalisée entre les composants)
afin d'atteindre les mêmes objectifs : maintenabilite du code, indépendance
entre le code et le déploiement (localisation, redondance).
J'espère ne pas m'attirer des foudres avec les deux paragraphes suivants.
La SOA est surtout mise en oeuvre dans le SI (système d'information) de
l'entreprise, avec des services s'exécutant sur des serveur d'applications
(bienvenue dans le monde de la JVM). La terminologie est précise (service
métier, service d'intégration, annuaire de services), des protocoles sont
préconisés et la mise en oeuvre est balisée (urbanisme, lotissement). La SOA
est mature et normalisée, elle a été pensée par des architectes logiciels
comme un ensemble de bonnes pratiques pour concevoir des applications non
monolithiques et évolutives.
A l'opposé, les microservices sont nés sur [le front
nuageux](https://fr.wikipedia.org/wiki/Cloud_computing), dans un environnement
plus dynamique (ajout à chaud d'instances de services pour supporter la
charge), très hétérogène (mix de plusieurs langages de programmation) avec des
contraintes fortes sur les temps de réponse (cas des sites de réservation ou
d'achat, réseau social). Nés un peu à l'arrache, c'est en grandissant qu'on
conceptualise progressivement leurs modèles de conception :
[http://microservices.io](http://microservices.io). Les microservices
remettent en question les façons de tester, déboguer, déployer, surveiller car
une application est constituée de très nombreux microservices, certains étant
prévus pour être répliqués afin d'absorber des pics de charges ; il ne
partagent souvent aucun socle commun (pas de serveur d'application) et ils
sont distribués sur des serveurs, des machines virtuelles ou des containers
Docker...
*"Marrant ton truc, ça rappelle un peu [la cathédrale et le bazar](https://fr.wikipedia.org/wiki/La_Cath%C3%A9drale_et_le_Bazar) non ?"*
- C'est pas faux ! D'ailleurs j'ai toujours eu un goût prononcé pour le bazar, à ne pas confondre avec le chaos. Et ce bazar fonctionne ; des grosses sociétés ont misé dessus : Facebook, Amazon, Netflix, Twitter...
Pour un développeur / architecte... Java EE (au hasard), s'intéresser aux
microservices c'est un peu comme être exfiltré du rayon condiments de
Carrefour et parachuté dans le marché aux épices d'Istanbul : un étiquetage
moins formel, pas de conditionnement normalisé mais beaucoup de couleurs et de
senteurs.
![Marché aux épices](/images/2017/epices.jpg)
Il n'est pas évident de s'y retrouver, aisé de faire des choix inappropriés
mais c'est plutôt excitant. Concrètement, on va utiliser le langage de
programmation le plus approprié pour chaque tâche (du Node.js, du Python, du
Golang ou autre), communiquer avec un modèle adapté au besoin (du RPC, de la
communication par message), choisir des protocoles adaptés à la taille des
informations échangés et aux contraintes (LAN, WAN, réseaux mobiles), fournir
une persistence locale à chaque microservice (quitte à redonder de
l'information) et surtout gérer finement le mode déconnecté (pas d'accès
réseau, inaccessibilité d'un service distant), autant que possible rendre un
service dégradé en cas de perturbation (faire mieux qu'une erreur *404 Not
Found*).
Ce projet GitHub recense les briques existantes pour construire des
microservices : [https://github.com/mfornos/awesome-
microservices](https://github.com/mfornos/awesome-microservices). Mon goût
prononcé pour Python m'a amené à jouer avec
[Nameko](https://nameko.readthedocs.io), puis à développer [un mini-
framework](https://github.com/kianby/microsvax) qui permet de communiquer par
message et RPC à travers une base mémoire [Redis](https://redis.io). Ca n'ira
jamais en production mais c'était amusant à faire. Je me suis intéressé au bus
de message ultra-rapide [NSQ](https://github.com/nsqio/nsq) écrit en Golang,
et dernièrement, je revois mon projet de service d'e-mail
[SRMail](https://github.com/kianby/srmail) dans une optique microservices.
Bref c'est un terrain de jeu illimité en connexion avec les révolutions
amenées par le développement dans les nuages, les objets connectés et le
DevOps : des domaines encore jeunes mais prometteurs qui réveillent les
~~papilles~~ neurones :-)

37
posts/2017/2017-12-25-un-blog-plus-respectueux.md Executable file
View file

@ -0,0 +1,37 @@
<!-- title: Un blog plus respectueux -->
<!-- category: Blog -->
<!-- tag: planet -->
Je suis allé plus loin dans le respect de la vie privée sur le blog.<!-- more -->
Quand on laisse un commentaire, l'adresse e-mail a toujours été optionnelle.
Elle sert à retrouver un avatar sur [Gravatar](https://fr.gravatar.com) et à
informer les abonnés de la parution d'un nouveau commentaire pour un article.
J'ai ajouté à [mon gestionnaire de
commentaires](https://github.com/kianby/stacosys) un mode *privé* qui
désactive la fonction d'abonnement et se passe de l'e-mail. En fait, l'e-mail
est résolu en avatar dans le navigateur avec quelques lignes de JavaScript et
il n'est pas pas envoyé au serveur, donc jamais stocké.
Le nouveau formulaire de ressemble à ceci :
![Commentaire en JS](/images/2017/commentaire-js.jpg)
L'autre nouveauté, dans la même veine, c'est le support des navigateurs avec
le JavaScript désactivé. Mon article précédent [*un blog plus statique*](/2017/un-
blog-plus-statique/) a fait la moitié du travail en générant en pur HTML les
commentaires déjà postés. Il restait à donner la possibilité de laisser un
commentaire sans JavaScript, c'est chose faite avec un mode dégradé :
- sans gestion de l'avatar
- sans prévisualisation en Markdown
Le formulaire sans JavaScript ressemble à ceci :
![Commentaire sans JS](/images/2017/commentaire-nojs.jpg)
Il me semble normal de ne pas empêcher les lecteurs les plus soucieux de leur
vie privée d'accéder aux commentaires, c'est en phase avec les valeurs que je
prône ici.