Lut.im : une tragé­die des communs évitée

Savez-vous ce qu’est la tragé­die des communs ? C’est quand une ressource commune est surex­ploi­tée et au final, tout le monde est perdant.

C’est un peu ce qui se passe en ce moment sur l’ins­tance offi­cielle de mon logi­ciel Lutim : https://lut.im.

En effet, depuis déjà quelques jours, ce site est inac­ces­sible en soirée. Trop d’uti­li­sa­teurs qui veulent voir trop d’images en même temps. Lut.im victime de son succès ?

Oui et non : oui car le site commence à être plutôt connu (surtout en Russie, allez savoir pourquoi) ; non car c’est un problème d’abus de la ressource commune qu’est lut.im : en effet, le problème vient de l’uti­li­sa­tion qui est en faite par quelques personnes.

Pour comprendre ce qui se passait, j’ai activé les logs d’ac­cès au service — en prenant soin de ne pas affi­cher les adresses des images deman­dées (voir plus bas) — et j’ai noté quelques adresses de refe­rer suspectes ainsi qu’un nombre incroyable de requêtes deman­dées par des user-agent Kodi et quelques XBMC.

J’ai été voir sur un des refe­rer suspects : un site de strea­ming de chaîne télé… et certains des logos des chaînes étaient héber­gés sur https://lut.im ! Ça m’a mis la puce à l’oreille quant aux user-agent Kodi. Un peu de recherche genre kodi tv channel "https://lut.im" et je tombe sur un truc comme http://www.listaiptv­bra­sil.com.br/paste.php?id=3 (oui, je savais qu’il y avait moyen de voir des chaînes de télé sur Kodi, j’en ai un et j’avais regardé si je pouvais voir des chaînes de télé mais j’avais au final laissé tomber, vu la qualité de ce qu’on peut voir à la télé (pis bon, la pub…)).

J’ai donc bloqué, pour éviter l’in­dis­po­ni­bi­lité fréquente de https://lut.im, les refe­rer de ce genre que j’ai trouvé ainsi que les user-agent Kodi et XBMC :

if ($http_referer ~ (site1|site2) {
    return 429;
}
if ($http_user_agent ~* (Kodi|XBMC)) {
    return 429;
}

Le statut 429 que je renvoie corres­pond à « Too Many Requests ». Disons que c’est le statut que j’ai trouvé le plus proche de la situa­tion. Certes, ce n’est pas le client qui fait trop de requêtes, mais bon.

La soirée d’hier s’est passée sans alerte de la part de la super­vi­sion et chaque fois que j’ai été voir le site, celui-ci était acces­sible ! Mes actions ont donc évité la surex­ploi­ta­tion de la ressource commune 🙂

Et voilà comment j’ai modi­fié le format de mon log d’ac­cès pour ne pas loguer les IPs de mes visi­teurs ni les URLs des images deman­dées :

log_format lutim '$remote_user [$time_local] $status $body_bytes_sent "$http_referer" "$http_user_agent" "$gzip_ratio"';
server {
    …
    access_log /var/log/nginx/lutim.access.log lutim;
    …
}

J’ai après cela remis la confi­gu­ra­tion à access_log off; et supprimé les jour­naux d’ac­cès.

Crédit : Photo de Brad Helmink sur Unsplash

Un bug à l’ex­port de VMs dans Ganeti

Encore un article sur un bug dans Ganeti.

Situa­tion : Debian Jessie, avec Ganeti 2.15.2–1~b­po8+1 prove­nant des back­ports Jessie.

Problème : ça foire quand on veut faire une sauve­garde d’une VM avec gnt-backup export ma_vm. Avec ce genre de message :

Fri Aug 11 12:08:36 2017  - WARNING: import 'import-disk0-2017-08-11_12_08_27-igVAWh' on mynode.mydomain failed: Exited with status 1
Fri Aug 11 12:08:36 2017 snapshot/0 failed to receive data: Exited with status 1 (recent output: socat: E openssl-method="TLSv1": method unknown or not provided by library)

Le bug est déjà connu de Debian et corri­gé… dans la version Stretch ! Pas la version Jessie-back­ports 🙁

Bon, c’est rien de bien méchant. Il suffit d’édi­ter le fichier /etc/ganeti/share/ganeti/impexpd/__init__.py et chan­ger les lignes

SOCAT_OPENSSL_OPTS = ["verify=1", "method=TLSv1",
                      "cipher=%s" % constants.OPENSSL_CIPHERS]

en

SOCAT_OPENSSL_OPTS = ["verify=0", "method=TLS1",
                      "cipher=%s" % constants.OPENSSL_CIPHERS]

Notez la modi­fi­ca­tion de verify et de method.

Et c’est tout bon !

Bien sûr, il vaut mieux passer son serveur en Stretch, mais avec les 70 machines de Frama­soft, j’ai du établir un plan­ning pour tenter de mini­mi­ser le nombre de services à tomber en même temps, du coup je n’y vais à un rythme que de une ou deux machines par jour (ça va, j’en suis à peu près à deux tiers de machines sous Stretch, un tiers sous Jessie et quelques unes encore sous Wheezy (diffi­cile de les upgra­der sans péter les logi­ciels qui sont dessus)).