En fait, c’est le ext4 de /tmp qui a été monté en read-only par le système pour éviter de tout pêter. Mais du coup, PHP et MailleScule n’aiment pas trop.

La solution temporaire a été de redem les deux process et bidouiller leur config pour que leurs fichiers temp tapent dans une partition saine, le temps de resoudre le problème.

Comme l’installation est bidouillée de chez bidouillée, on a vraiment pas envie de tout réinstaller, donc on fait de l’acharnement thérapeutique pour sauver ce serveur.

Bref, vive l’auto-hébergement !

C’est terrible ça, une vrai maladie. Ça me donne envie de faire des vidéos comme le joueur du Grenier pour râler à voix haute.

Bref.

Donc WSGI a le même but que FastCGI, SCGI, or AJP : c’est une norme qui sert à définir comment un serveur Python et son application peuvent discuter. Ça été pondu pour que tous les serveurs et toutes les applications Python qui respectent la norme soient garantis de pouvoir s’interfacer.

Ça, c’est la définition que vous voyez partout. Super, mais concrètement ça veut dire quoi ?

WSGI, c’est juste une convention de discussion

Un bon dessin vaut mieux…

C'est compliqué de faire un schéma comme ça sérieux ? Ah ça pond une norme de 30 pages mais ça peut pas faire 3 ronds dans paint.

D’un côté vous avez des serveurs comme ceux de cherrypy, de paste, de werkzeug ou comme la commande runserver de Django, ou tels que les serveurs gunicorn, Apache (avec mod_wsgi). Ces logiciels ont pour boulot d’accueillir une requête HTTP et de renvoyer la réponse. Ils ont des problématiques comme : gérer les sockets, gérer plusieurs processus en parallèle, éviter qu’un pirate se balade sur votre serveur, etc.

De l’autre côté vous avez votre application. 9 fois sur 10, votre site Web, donc votre code. Sa problématique c’est de recevoir une requête, la comprendre, et générer une réponse en tapant dans la base de données, et en faisant sa popotte HTML.

Il faut donc que votre serveur dialogue avec votre app, qu’il lui passe la requête, que votre app la gère, retourne la réponse, et file la réponse au serveur. Alors le serveur envoie la réponse au navigateur.

C’est la chose la plus mal expliquée : il y a deux parties à WSGI. Une pour le serveur, et une pour l’application.

Un serveur est dit “compatible WSGI” quand il est capable de transmettre une requête HTTP normale à votre application via le protocole WSGI, et qu’il est capable de récupérer une réponse HTTP depuis votre application via le protocole WSGI pour en faire une requête HTTP normale.

Une application est dite “compatible WSGI” quand elle est capable de recevoir une requête HTTP transformée en un objet Python selon la norme WSGI, et qu’elle retourne une réponse HTTP sous la forme d’un objet Python selon la norme WSGI.

J’avais demandé concrètement, show me the fucking code !

Côté serveur WSGI, on doit lui passer le point d’entrée de votre app.

Le point d’entrée est un module Python qui contient une variable nommé application.

C’est tout.

La variable application doit contenir votre application compatible WSGI.

Une application compatible WSGI a un certain nombre de méthodes pour accepter en paramètres un objet requête HTTP, et retourner un objet réponse HTTP, mais la bonne nouvelle, c’est que vous n’avez absolument pas besoin de savoir comment ça marche.

En effet, tous les frameworks compatibles WSGI (bottle, django, cherrypy, etc) ont une fonction qui retourne cette application toute faite.

Par exemple, avec bottle, mon fichier wsgi va contenir :

from site import app
 
application = app

C’est tout. app, le décorateur qui permet de faire @app.route('/') dans le code du site bottle, est déjà une application WSGI.

Pour Django, ça va donner un truc comme :

import os
# ont dit quel est le module de settings Django
os.environ["DJANGO_SETTINGS_MODULE"] = "project.settings"
 
# et on fabrique l'application WSGI avec une fonction
# que Django nous donne
from django.core.wsgi import get_wsgi_application
 
application = get_wsgi_application()

Le simple fait qu’il y ait une variable nommée application fait que le serveur va se débrouiller. Tout ce qu’il y a à faire, c’est passer en paramètre ce module au serveur, et comment le faire dépend du serveur.

Par exemple pour gunicorn, c’est le premier paramètre de la commande qu’on utilise pour lancer le serveur :

gunicorn nom_du_module

Il faut que le module soit importable (on peut passer l’option --pythonpath pour s’en assurer.)

Pour Apache et mod_wsgi, ça se fait dans le fichier de config apache.conf:

WSGIScriptAlias / /chemin/version/module.wsgi

Bref, faire dialoguer un serveur et une application WSGI, c’est con comme la lune :

1. Faire un module qui contient une variable nommée application contenant l’app WSGI.
2. Dire au serveur où se trouve le fichier

Avantages et inconvénients de WSGI

Parmi les avantages, on retrouve :

• Pas de parsing de la requête au niveau de l’application.
• Entrée de toutes les apps WSGI normalisées.
• Tous les logiciels WSGI sont compatibles entre eux.
• Le module WSGI reste chargé en mémoire une bonne fois pour toute, pas besoin de le recréer à chaque requête.
• WSGI se suffit à lui même pour écrire une application. Dans la théorie, on n’a même pas besoin de framework.

Quant aux inconvénients :

• En pratique il y a très peu de code partagé entre les applications WSGI. La communication sur WSGI s’est très mal passée et cela reste quelque chose de mystérieux pour la plupart des développeurs.
• WSGI ne gère pas les websockets, et la norme est en train d’être mise à jour pour cela. Mais cela prend du temps et les websockets sont déjà là, du coup les gens se tournent vers des solutions non WSGI (tornado, twisted, etc).
• Certains serveurs ne gèrent pas WSGI (comme nginx ou lighttpd), du coup on ne peut pas communiquer directement entre l’app et eux. Il faut un intermédiaire. C’est pour cela qu’on voit très souvent des setups comme nginx <=> gunicorn <=> django, avec un serveur WSGI qui sert d’intermédiaire. Il y a tout de même le bénéfice de pouvoir gérer parfaitement indépendamment le processus WSGI du serveur HTTP, ce qui est très pratique pour le debug, l’administration système, le déploiement, etc.
• WSGI, c’est du Python. Qui dit Python, dit import, qui dit import, dit PYTHON PATH. 90% des erreurs de mise en prod sont des erreurs d’import, et pour cette raison sys.path est presque toujours manipulé dans un fichier qui contient une application WSGI.

Pour la culture

Voici à quoi ressemble un hello world en WSGI :

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    yield 'Hello World\n'

Et oui, c’est très simple, et il n’y a rien à importer. La norme WSGI est une convention : il doit y avoir une variable nommée application (ici la variable c’est le nom de la fonction), et cette variable doit contenir une application WSGI.

Mais une application WSGI, c’est juste un callable (ici une fonction) qui accepte en paramètres environ (la requête), start_response (une fonction qui écrit l’en-tête de la réponse) et qui retourne un générateur de string. C’est tout.

Il n’y a rien de magique. C’est une simple interface sur laquelle tout le monde s’est mis d’accord.

Quand on fait en Django:

application = get_wsgi_application()

En fait Django ne fait que fabriquer une fonction comme on vient de voir, qui derrière appelle votre application Django.

En revanche, comme on utilise souvent Django derrière nginx, le setup ressemble très souvent à ça :

Quand on voit "socket", ça fait peur, mais c'est juste une ligne de config qui point généralement vers localhost:8000.

Faire tourner bitcoinqt sur son ordinateur personnel a plusieurs défauts :

• Il télécharge toute la blockchain, ce qui est long et prend des Go de place sur le disque.
• Ca bouffe de la ressource pour rien.
• On aide pas tellement le réseau car on ferme le client dès que l’opération financière est terminée.

Bref, le client officiel Bitcoin n’est pas le plus ergonomique, et on lui préférera des alternatives légères comme Electrum.

Seulement puisque ces wallets “allégés” ne télécharge pas la blockchain, vous n’aidez pas le réseau. Or, personnellement, je participe à Bitcoin pour aider le mouvement.

J’ai donc décidé d’installer un nœud Bitcoin sur un de mes serveur, comme ça j’ai le meilleur des deux mondes. Évidement je ne recommande pas à Mme Michu de faire ça, mais en même temps je ne recommande pas à la vieille d’utiliser Bitcoin non plus.

Sur Ubuntu Server, ce n’est pas une opération complexe.

Créer un utilisateur nommé “bitcoin”

Ca permet d’isoler les fichiers de config (le wallet sera vide de toute façon, je suis pas fou).

sudo adduser bitcoin

Installer le daemon bitcoin

Cool, c’est dans les dépôts !

sudo apt-get install bitcoind

Faire un script de démarrage

Alors là, je m’attendais à une galère sans nom, mais c’est sans compter qu’Ubuntu utilise maintenant upstarts, qui rend la création de scripts de démarrage super simple.

Créer un fichier /etc/init/bitcoin.conf et mettre dedans:

# bitcoind upstart script for Ubuntu
 
description "Bitcoin daemon"
 
start on runlevel [2345]
stop on runlevel [!2345]
 
respawn
exec su -c "bitcoind" - bitcoin

Pouf pouf, on démarre le service :

service bitcoin start

Et voilà, bitcoind est maintenant un service de votre serveur, tournant vaillamment en tâche de fond, lancé à chaque reboot.

Ouvrir le port 8333

Sinon vous aurez un super service qui tourne pour lui tout seul.

sudo iptables -I OUTPUT -p tcp -m tcp --dport 8333 -j ACCEPT
sudo iptables -I INPUT -p tcp -m tcp --dport 8333 -j ACCEPT

Vérifier si ça marche :

du -sH /home/bitcoin/.bitcoin

La taille devrait grossir avec le temps

Prochaine étape, faire son propre serveur de blockchain, histoire de ne pas dépendre de ceux d’electrum.

PS: passer l’option “-gen” à bitcoind si vous voulez miner. Ça vous servira à rien, mais c’est psychologique ^^

La procédure pour l’installation sur Ubuntu est beaucoup plus simple qu’au début du projet.

D’abord, il faut récupérer le nom de sa distrib :

lsb_release -c
Codename: precise

Ici pour pour moi “precise”.

Ensuite on rajoute /etc/apt/sources.list une ligne contenant deb http://deb.torproject.org/torproject.org nom_distrib main, dans mon cas :

deb http://deb.torproject.org/torproject.org precise main

On rajoute les clés du dépôt officiel de tor et on install tor (ntp pour synchroniser l’heure) :

gpg --keyserver keys.gnupg.net --recv 886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
sudo apt-get update
sudo apt-get install deb.torproject.org-keyring tor ntp

A ce stade là vous avez un client Tor fonctionel, mais pas un nœd de sortie. Un petit sudo vi /etc/tor/torrc et on décommente la ligne :

#ORPort 9001

Il faut du coup ouvrir le port 9001 :

iptables -I INPUT -p tcp -m tcp --dport 9001 -j ACCEPT
iptables -I OUTPUT -p tcp -m tcp --dport 9001 -j ACCEPT

(Sauvegardez votre config iptables sinon au prochain reboot, votre port est à nouveau bloqué)

Et on relance le service.

sudo service tor reload

Pour voir si ça a bien fonctionné :

cat /var/log/tor/log | grep test
Self-testing indicates your ORPort is reachable from the outside. Excellent.

Quelques avertissements tout de même :

• Tor est un projet utilisé massivement par des activistes politiques et personnes à la connexion internet et aux libertés bridées (c’est ceux qu’on cherche à aider), mais également des gens aux activités illégales (ventes de produits interdits dans leurs pays, ce qui va de la weed au GHB) voir carrément immorales (pédopornographie, terrorisme). En ouvrant un nœud Tor, vous n’avez aucun contrôle sur QUI utilise votre équipement, ou pour faire quoi.
• Certains hébergeurs interdisent Tor. C’est le cas de cinfu, un hébergeur qui accepte pourtant les Bitcoins mais aussi, je viens de l’apprendre à mes dépends, de online.net et ses fameuses dédibox. Il m’ont donné 24 H pour fermer mon nœd Tor, et je vais donc devoir le migrer sur leaseweb ou OVH.
• Le cadre légal autour de Tor est encore fluctuant. Je suis incapable de vous dire si vous pouvez être tenu pour responsable des activités illégales qui seraient perpétrées à travers votre équipement.
• Ça va bouffer de la bande passante.

Non ?

Comme ce sont des machines virtuelles, le problème s’est manifesté à notre niveau sous la forme d’un iowait de plus de 90% à la cause impossible à diagnostiquer et qui impliquait de fortes lenteurs sur le blog (et tous nos autres sites) jusqu’à ce qu’on force un reboot (juste sur le blog :-p).

C’était une mauvaise idée, puisque le serveur est devenu injoignable (alors que les autres tournaient mal, mais tournaient).

Au final, leaseweb à bien réagi en communiquant rapidement sur le problème et en remettant le truc d’équerre rapidement.

Ça nous a permis de réaliser que bien qu’on ait un backup du blog, on avait pas de backup de 0bin. C’est maintenant chose faite.

Comme on critique beaucoup Twitter en ce moment, au moins un point positif c’est que quand on se pête la gueule, on peut continuer à communiquer par ce genre de services tiers. Le could-social-over-hyper-3.0 n’a pas que du mauvais.

@+ dans le bus

Rediriger “www” avec Apache

On peut mettre la redirection dans les fichiers de configuration Apache, mais le plus simple est de créer un fichier .htaccess dans le dossier qui contient tout le code de votre site Web, et d’y mettre le code qui gère la redirection.

Pour rediriger de “www” vers l’adresse sans “www”


RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.*) [NC]
RewriteRule ^(.*) http://%1/$1 [R=301,L]

Pour rediriger l’adresse sans “www” vers “www”

RewriteEngine On
RewriteCond %{HTTP_HOST} ^votresupersiteweb\.com$ [NC]
RewriteRule ^(.*)$ http://www.votresupersiteweb.com/$1 [R=301,L]

Pour que la redirection marche, il faut vous assurer que le module mod_rewrite d’Apache est installé et activé, ce qui est la cas dans la plupart des installations et hébergeurs par défaut.

Rediriger “www” avec Nginx

Il faut mettre la redirection dans le fichier de configuration de votre site, généralement situé dans /etc/nginx/conf.d/. Vous avez besoin que nginx soit compilé avec le module rewrite, ce qui est le cas par défaut.

Pour rediriger de “www” vers l’adresse sans “www”

server {
listen 80;
server_name www.votresupersiteweb.com;
rewrite ^/(.*) http://votresupersiteweb.com/$1 permanent;
}

Pour rediriger l’adresse sans “www” vers “www”

server {
listen 80;
server_name votresupersiteweb.com;
rewrite ^/(.*) http://www.votresupersiteweb.com/$1 permanent;
}

Si vous avez déjà un bloc “server”, mettez celui-ci au dessus du précédent. Redémarrez Nginx pour que les changements soient pris en compte.

Rediriger “www” avec Lighttpd

Assurez vous que le module “mod_redirect” est activé dans le fichier de configuration de Lighttpd.
This trick requires mod_redirect module. You should put it close to the top of the configuration file before other redirect or rewrite rules.

Pour rediriger de “www” vers l’adresse sans “www”

$HTTP["host"] =~ "^www\.(.*)$" {
url.redirect = ( "^/(.*)" => "http://%1/$1" )
}


Pour rediriger l’adresse sans “www” vers “www”

$HTTP["host"] =~ "^votresupersiteweb\.com$" {
url.redirect = ( "^/(.*)" => "http://www.votresupersiteweb.com/$1" )
}

Redémarrez Lighttpd pour que les changements soient pris en compte.