PROJET AUTOBLOG


Sam et Max

source: Sam et Max

⇐ retour index

L’erreur “broken pipe” avec les serveurs Python tel Gunicorn

vendredi 26 avril 2013 à 08:46

Quand on commence à avoir pas mal de trafic sur son site, on commence à noter l’apparition d’une erreur inquiétante :

Traceback (most recent call last):
File "gunicorn/workers/async.py", line 44, in handle
self.handle_request(req, client, addr)
File "gunicorn/workers/ggevent.py", line 88, in handle_request
super(GeventWorker, self).handle_request(*args)
File "gunicorn/workers/async.py", line 83, in handle_request
resp.write(item)
File "gunicorn/http/wsgi.py", line 275, in write
util.write(self.sock, arg, self.chunked)
File "gunicorn/util.py", line 232, in write
sock.sendall(data)
File "gevent/socket.py", line 480, in sendall
data_sent += self.send(_get_memory(data, data_sent), flags)
File "gevent/socket.py", line 451, in send
return sock.send(data, flags)
error: [Errno 32] Broken pipe

Et plus il y a de trafic, plus cette erreur apparait dans les logs.

Pourtant, impossible de trouver la cause de l’erreur, tout semble bien marcher, le serveur pète la forme et ipdb ne donne rien du tout.

La raison pour laquelle vous ne trouvez rien, c’est qu’il n’y a rien à trouver. Cette erreur est levée par le module socket quand il essaye d’écrire sur une connexion qui s’est fermée brutalement.

Or le serveur ne peut pas savoir quand une connexion s’est fermée si le client ne lui envoie pas le message. Et il peut y avoir énormément de raisons pour que ça arrive : fermeture d’un onglet en plein chargement, crash du navigateur, extinction du PC pendant la réponse, etc.

Vous en voyez plus quand le trafic augmente tout simplement parce que statistiquement, avec plus de visiteurs, ces situations rares se rencontrent plus facilement dans la masse de connexions.

Donc pour l’erreur “broken pipe”, il n’y a rien à faire, à part de monter le log level de votre serveur d’un cran pour qu’il n’affiche plus ça dans vos logs.

flattr this!

Pourquoi les éditeurs s’en foutent que les DRM n’empêchent pas le piratage

jeudi 25 avril 2013 à 08:19

Ce qui m’a toujours amusé avec les activistes, c’est leur capacité à s’exclamer devant la bêtise de ceux qu’ils critiquent alors qu’ils n’ont simplement pas compris leurs motivations.

Par exemple, dans le cas des DRM, le débat est orienté sur leur efficacité. J’ai été le premier à dire : “les DRM, c’est idiot, ça n’a jamais empêché le piratage.”

Sauf que ce n’est pas le but.

C’est le but annoncé, certes, car il faut bien le vendre à l’état et l’opinion publique. Mais c’est comme la pédophilie, les néo-nazis, les terroristes et le petit déjeuner équilibré, simplement quelque chose qu’on brandit en avant pour que les gens dépensent leur énergie sur ce débat alors que la stratégie est ailleurs.

Le but premier des DRM est le contrôle du marché. C’est simplement la bonne vieille stratégie des formats qu’on a vu évoluer dans les années 90 avec la bureautique qui s’est adaptée.

Aujourd’hui les informaticiens sont OPÉ sur les formats, il savent qu’ils faut se méfier. Et les gens aussi.

Alors on vend des formats ouverts, et on colle juste des mesures de protections par dessus. C’est la même chose, mais en différent.

Cette stratégie de répéter encore et toujours le même procédé sous une forme différente à toujours marché à travers l’histoire. Les gens ont de la mémoire, mais pas l’opinion publique et le débat, ainsi que tous les efforts de ceux qui ont combattu pour éviter la merde de la vague précédente, vont devoir repartir de zéro.

Pour les fournisseurs de DRM, c’est tout bénef :

Rien d’étonnant que les DRM soient donc fournis avant tout par des éditeurs de solutions (MS, Apple, Adobe), et pas du tout par les éditeurs de contenu : le but est le contrôle du marché en jouant sur la peur des majors, pas du tout d’éviter le piratage.

Et cet article ne sert à rien. Car seuls ceux qui sont déjà convaincus de l’importance d’éviter les DRM vont le lire. Ils vont essayer de se débattre, et puis pouf, on changera de cheval de bataille. On ressortira la même sauce, mais en différent.

Par exemple, les DRM, ça ne sert à rien si on a pas une bonne authentification.

On parie que le prochain débat, c’est une solution d’identification unique de chaque usager pour éviter le terrorisme, le plagiat, l’appel à la haine et la diffamation ? L’anonymat et le vol d’identité c’est grave ma p’tite dame. Et les activistes derrière : ouiiiii, mais c’est une atteinte à la liberté, tout ça ! Et ce sera vrai. Mais ce sera encore un faux débat, car derrière, les gars veulent juste contrôler la chaîne de diffusion des produits.

flattr this!

Monitorez vos serveurs avec munin et notifications par email

mercredi 24 avril 2013 à 08:02

Avoir un serveur c’est bien, en prendre soins c’est mieux. J’ai longtemps administré des serveurs sans trop me soucier de ce qui pouvait leur arriver et bien des fois tout a planté car je n’avais pas su anticiper la catastrophe.
Un exemple courant, j’ai viré Apache pour installer Nginx et ce dernier log par defaut les acces http, après quelques semaines, le disque dur bien rempli, le serveur me claque dans les doigts, plus de place, tout merde, c’est le drâme, pas moyen de rebooter à part en safe mode car disque plein, les hémoroïdes s’en mêle, c’est foutu.

J’ai commencé par MRTG, pas terrible à installer mais il fait son boulot. Et puis j’ai changé de serveurs pas mal de fois en une année, horrible d’avoir à réinstaller ce truc à chaque fois alors j’ai cherché autre chose, après quelques tests pas terribles je suis tombé sur munin, plutôt complet avec des plugins que l’on peut écrire soit-même. Facile à installer quand on utilise les packages, suivez le guide.

Installation de Munin:
Munin se compose de deux programmes.
Le maître (munin): qui va récupérer les infos et générer les graphs.
Le noeud (munin-node): qui s’installe sur tous les serveurs à monitorer y compris le maître si besoin et qui va envoyer les infos au maître.

Sur le serveur Maître pour une distribution Ubuntu:

sudo apt-get install munin munin-node munin-plugins-extra
sudo ln -s /var/cache/munin/www /var/www/munin
sudo /etc/init.d/munin-node restart

Pour voir s’afficher les pages il vous faudra un serveur web, exemple avec Nginx:
dans le répertoire conf.d de Nginx ajoutez un fichier munin.conf et mettez-y le code suivant.

vi /usr/local/nginx/conf.d/munin.conf
server {
 
    listen       80;
    server_name munin.monserveur.com;
 
	location / {
	        auth_basic            "Restricted";
	        # Create the htpasswd file with the htpasswd tool.
	        auth_basic_user_file  /etc/nginx/htpasswd;
 
	        root /var/www/munin/;
	        index  index.html index.htm;
	        expires modified +310s;
	}
}

Note: vous pouvez désactiver l’authentification si vous voulez rendre votre page publique.

Après réglages de vos DNS chez votre registrar vous devriez avoir quelque chose à la page http://munin.monserveur.com

Sur les serveurs à monitorer (les noeuds):

sudo apt-get install munin-node munin-plugins-extra

Il faut maintenant “dire” au serveur noeud l’IP du serveur maître pour qu’il puisse lui envoyer les informations sur l’état de la machine.

Editez le fichier /etc/munin/munin-node.conf

allow ^192\.168\.1\.200$

Cette partie va permettre au Maître de venir récupérer les infos nécessaires. Remplacez l’IP par celle de votre serveur Maître.

On redemarre munin-node pour prendre en compte les changements.

sudo /etc/init.d/munin-node restart

PS: Si il ne se passe rien vérifiez que vous n’avez pas un firewall qui bloque l’IP et/ou le port TCP/4949

Les plugins:
Les plugins sont des petits programmes permettant de rajouter des fonctionnalitées au monitoring comme la supervision de services tels que Redis, Varnish, Nginx, etc. La liste est ici

Attention: L’ajout des plugins se fait côté serveur Noeud !

En fait il s’agit de simples liens symboliques dans le répertoire /etc/munin/plugins/ pointants vers le répertoire /usr/share/munin/plugins/.
La liste des plugins disponibles s’obtient avec:

sudo munin-node-configure

Exemple rajouter le plugin pour monitorer Mysql:

ln -s /usr/share/munin/plugins/mysql_queries /etc/munin/plugins/mysql_queries

Mysql en train de mourir...

Après que les machines noeuds aient été configurées on les déclarent au serveur Maître:
Il faut éditer le fichier munin.conf sur le serveur Maître.

vi  /etc/munin/munin.conf
[sametmax]
    address sametmax.com
    df._home.warning 95
    use_node_name yes
 
[machine_locale_maitre]
    address  127.0.0.1
    use_node_name yes
 
[groupe_de_serveurs;]
    address  127.0.0.1
    use_node_name yes
 
[groupe_de_serveurs;serveur_adolf]
    address  33.94.124.33
    use_node_name yes
 
[groupe_de_serveurs;serveur_himler]
    address  33.94.124.33
    use_node_name yes
 
[groupe_de_serveurs;serveur_DSK]
    address  69.69.69.69
    use_node_name yes

Analysons la config ci-dessus:

sametmax:
Le premier va nous sortir les stats du serveur sametmax.com, on peut mettre l’ip comme le nom de domaine.

machine_locale_maitre:
Si on veut monitorer la machine maitre on met 127.0.0.1

groupe_de_serveurs:
Va définir un groupe de serveurs, l’affichage groupera tous les serveurs y appartenant, c’est juste pour un affichage plus clair, ne pas oublier le “;” à la fin

groupe_de_serveurs;serveur_adolf:
Un serveur qui apparaîtra dans le groupe de serveurs avec himler et DSK

Notification par email:
Avec munin il est possible de recevoir des notifications lorsque certains capteurs de votre monitoring atteignent un certain seuil.

Vérifiez bien que sendmail est installé et qu’il fonctionne
Dans le shell on teste sendmail

echo 'Promo sur les BBW' | mail -s 'sujet à poil les putes' monmail@moi.com

Toujours dans le fichier munin.conf sur le serveur Maître:

#email notifications settings
contacts max
contact.max.command mail -s "Munin notif ${var:host}" monmail@moi.com
contact.max.always_send warning critical

La premiere ligne définie un contact, la deuxième va envoyer l’email de notification via sendmail au mail indiqué.
La dernière ligne va indiquer à munin qu’il faut envoyer les alertes pour les warning et les critical.

Les seuils pour les notifications sont définis par warning et critical. Regardez plus haut pour le serveur [sametmax] nous avons défini un seuil pour df (disk free) de 95%.

[sametmax]
    address sametmax.com
    df._home.warning 95
    use_node_name yes

Ce qui veut dire que lorsque l’usage disque de /home aura dépassé les 95% d’utilisation munin va vous envoyer une notification par email. ça peut devenir lourd à la longue par contre car il s’arrête jamais :)

On redémarre munin sur le serveur mettre pour prendre en compte les modif:

su - munin --shell=/bin/bash
/usr/share/munin/munin-update

Bon monitorage!

flattr this!

Debuggez django avec –trace

mardi 23 avril 2013 à 23:50

C’est con mais toujours bon ça savoir : si manage.py ou django-admin vous font des misères, vous pouvez les rendre plus verbeuses avec l’option --trace.

Par défaut, elles n’affichent qu’un message, avec cette option on se retrouve avec le stack trace complet et surtout l’exception levée.

flattr this!

Créer un snippet pour Sublime Text

lundi 22 avril 2013 à 10:44

Un petit truc sympa avec Sublime Text c’est les snippets. une sorte de bout de code qui permet de faciliter la vie à bon nombre de feignasses dont je fais partie.
Ce bout de code va vous permettre d’afficher du texte prédéfini lorsque vous rentrerez le mot-clef correspondant suivi de la touche Tab.

Dans Sublime:
Dans tools > New Snippet. Vous allez voir apparaître un squelette d’un snippet prérempli.
Modifiez-le pour obtenir le code suivant.

<!-- Un snippet pour afficher une balise pre pour mes articles wordpress -->
<snippet>
	<content><![CDATA[
< pre lang="bash">$SELECTION</ pre>
]]></content>
	<tabTrigger>pre</tabTrigger>
	<!-- Optional: Set a scope to limit where the snippet will trigger -->
	<!-- <scope>source.python</scope> -->
</snippet>

Content:
Content va contenir le texte à afficher, vous avez la possibilité d’y ajouter des variables d’environnement comme récupérer le texte sélectionné avant le déclenchement du snippet (var: $SELECTION)

tabTrigger:
c’est le mot-clef suivi de la touche TAB qui va déclencher l’insertion du snippet, en général je prends les premières lettre du snippet que je veux déclencher (ipdb, pre, biatch)

scope:
Va définir le type d’environnement dans lequel on va pouvoir executer le snippet, source.python ne proposera le snippet que dans du code python. source.php pour php, etc.

Sauvegardez votre snippet et dans le cas présent entrez le mot-clef “pre” suivit de la touche TAB et ho miracle un joli texte prérempli apparaît. Si vous avez sélectionné du texte avant il sera inclu à la place de la variable $SELECTION (d’ailleurs à ce propos je n’ai pas trouvé comment le faire tout au clavier sans passer par le menu tools > snippet car la selection est remplacée par le mot-clef au clavier).

ATTENTION: sauvegardez bien votre snippet avec l’extension sublime-snippet sinon vous ne verrez pas apparaître votre snippet lors de son invocation.

Il y a d’autres options comme préremplir des bout de texte ou utiliser des regex.

J’en use et en abuse comme toute bonne feignasse qui se respecte.

flattr this!