Catégories
Blog Open-source Web

Le panier du marché libre #9

Après une très (trop) longue absence, voici la neuvième édition du panier du marché libre avec ces quelques liens qui, je le pense, vont vous intéresser:

Bientôt les belles journées, donc en bonus, la recette du VRAI Pan Bagnat Niçois (par pitié pas de salade dans le Pan Bagnat !!!)

Catégories
Blog Open-source Planet-libre Reseau Systeme Web

Varnish n’a pas peur de la montée en charge

Ce matin, un tweet de Philippe Scoffoni m’a permis de re-découvrir le site Load Impact qui permet de tester la montée en charge de votre service Web en simulant un nombre croissant de connexion. J’ai profité de cet outil sympa pour tester les performances de mon blog sans et avec le proxy cache Varnish (dont j’avais détaillé l’installation dans ce billet).

Avant de commencer la comparaison, un détail de ma configuration serveur:

  • Hébergeur Gandi
  • OS Ubuntu 10.04 LTS
  • CPU 1 coeur avec 1 Go de RAM

Perfos sans Varnish

Le test est alors effectué dans l’architecture suivante:

On obtient ces résultats:

Sans grande surprise on voit que les performances s’écroulent quand le nombre de lecteurs simultanés augmente. Pour 50 lecteurs simultanés sur le Blog (ce qui est quand même un pic que je ne vois pas tous les jours :)), on a un temps de chargement de la page qui passe à plus de 25 secondes (alors qu’il est de moins d’une seconde quand il y a un seul lecteur).

Perfos avec Varnish

En ajoutant Varnish en front-end à Apache, on a l’architecture suivante:

Et les résultats…

… sont à la hauteur des attentes de Varnish !

En effet pour 50 lecteurs consultant le blog en simultané, le temps de chargement ne dépasse pas les 2 secondes. Pas mal pour un logiciel qui ne prend que 1 Go d’espace disque…

Alors vous attendez quoi pour passer à Varnish ?

Catégories
Blog Web

Quelques news du blog

Je profite du retour du printemps pour vous donner, chers lecteurs, quelques nouvelles du Blog de Nicolargo.

On commence par le trafic en constante augmentation depuis le hack et l’indisponibilité du site en août 2010, avec un pic à plus de 240.000 pages vues sur le dernier mois courant. Les pages traitant de Nagios et de la supervision réseau arrivent toujours en tête des classements, mais je note un intérêt grandissant pour les sujets techniques sur l’hébergement et les logiciels d’expertises réseau (pour lesquels je viens de créer une page dédiée).

On peut également noter le succès des billets sur la sécurisation des serveurs de blog WordPress et le eBook gratuit sur Nagios (plus de 2300 téléchargements).

Comme vous avez pu le voir, le nouveau thème (design) est maintenant finalisé depuis quelques mois et m’apporte entière satisfaction. J’en ai profité pour revoir la monétisation du site. Il y a 4 blocs d’annonces au format 125×125 disponible dans la barre de menu de droite. Je remercie au passage les annonceurs avec qui je travaille. Si vous avez un peu de temps, merci de visiter leurs site, j’essaye de travailler avec des partenaires dont je partage la philosophie des logiciels libres. En plus des ces blocs partenaires, j’ai, sur les billets de plus d’une semaine, une bannière vidéo qui s’affiche en haut des billets et une annonce Google Adsense en bas.

Le chiffre dont je suis le plus fier ? C’est le ratio commentaires / article qui est de 7 !

Au delà des ces chiffres, je vous remercie pour les échanges que l’on peut avoir sur Twitter, dans les commentaires ou par mail !

Catégories
Blog Web

Un blog en héritage ?

L’age aidant, j’ai été emmené à réfléchir sur les questions d’héritages de mes biens au cas au je casserai ma pipe du jour au lendemain. Aucune inquiétude à avoir, je suis en bonne santé et le moral est là mais c’est un fait, tout peut arriver.

Passé les choses importantes (habitation, biens financiers, objets personnels…), tout blogueur est en droit de se poser cette question: « Que deviendra mon blog quand je  ne serais plus là ? ».

En effet, la grande majorité des blog personnels, comme le mien, ne sont gérés que par une seule personne. Celle-ci, en plus de rédiger les billets et de répondre aux commentaires, s’occupe de l’administration système (mise à jour de sécurité)  et des taches administratives (renouvellement du contrat d’hébergement et du nom de domaine).

Si ce bloguer décède, la fin du contrat chez l’hébergeur sonnera comme la fin de vie de son blog qui ne sera plus accessible.  Dur de voir tout son travail et ses données disparaître comme cela. Il existe bien des projets comme Internet Archive qui s’occupe d’archiver votre site à intervalle plus ou moins régulier. Le problème avec ce genre d’archivage est qu’il propose une image de votre site à un instant t. Il ne gère pas les options dynamiques comme les commentaires.

A titre personnel, je souhaiterai que mon blog continu à être accessible aux lecteurs et idéalement qu’il soit repris par des personnes partageant les mêmes intérêts. A ma connaissance, il n’existe pas en dehors du testament, de service permettant de transmettre les informations nécessaires à l’administration d’un site à une ou plusieurs personnes de confiance.

Si certains d’entre vous se sont posés ce genre de questions (blogueur, notaires, hébergeur), je serais curieux d’avoir leurs retours.

Catégories
Blog Open-source Web

Le panier du marché libre #8

C’est la saison des pois chiches, alors on prend son petit panier et on va glaner les bons liens de Nicolargo:

En bonus la recette de la socca Niçoise (il ne faut pas faire le petit bras avec le poivre…)

Catégories
Open-source Planet-libre Web

Supprimer les logs Apache « internal dummy connection »

Si comme moi vous avez des tonnes d’entrées du type:

::1 - - [10/Mar/2011:10:41:50 +0000] "OPTIONS * HTTP/1.0" 200 - "-" "Apache (internal dummy connection)"

dans les fichiers de logs de votre serveur Apache, voici une procédure simple pour les supprimer.

On commence par éditer le fichier de configuration /etc/apache2/apache2.conf pour créer un filtre nommé local:

# Filters

SetEnvIf Remote_Addr « 127\.0\.0\.1 » local

SetEnvIf Remote_Addr « \:\:1 » local

Ensuite, on doit activer ce filtre le fichier de définition de votre site (sous le répertoire /etc/apache2/site-enabled). Il faut modifier la ligne suivante:

CustomLog /var/log/apache2/www-access.log combined env=!local

Puis on relance Apache:

sudo apache2ctl restart

Et hop…

Sources:

Catégories
Gstreamer Open-source Planet-libre Video Web

Un serveur RTSP basé sur GStreamer

Dans le petit monde du streaming vidéo, RTSP est un protocole permettant à un client (lecteur multimédia) de contrôler un serveur (serveur de streaming) en lui envoyant des ordres simples: lire, pause, stop, déplacement temporel (pour avoir une liste des fonctions théoriquement disponibles, vous pouvez lire la RFC 2326). Il est important, pour comprendre la suite de ce billet que le protocole RTSP ne fait pas lui même le streaming vidéo (il utilise pour cela le protocole RTP). RTSP est juste une couche complémentaire permettant de contrôler ce streaming.

Nous allons dans ce billet étudier un serveur basé sur le framework GStreamer. Maintenu par Wim Taymans, un des développeurs de GStreamer, gst-rtsp se compose d’un ensemble de librairies permettant de concevoir simplement son propre serveur RTSP. Pour effectuer des tests, les développeurs fournissent quelques exemples de serveurs.

Installation de gst-rtsp

On commence par récupérer les sources puis à compiler:

mkdir ~/src

cd ~/src

wget http://gstreamer.freedesktop.org/src/gst-rtsp/gst-rtsp-0.10.8.tar.bz2

bzip2 -d gst-rtsp-0.10.8.tar.bz2

tar xvf gst-rtsp-0.10.8.tar

cd gst-rtsp-0.10.8/

./configure

make

Premier streaming RTSP: la mire

On commence par lancer le serveur de test qui va streamer une mire:

cd examples/

./test-readme

Le serveur est maintenant lancé, en écoute sur le port TCP/8554 et l’URL: rtsp://127.0.0.1:8554/test

Note: si vous lancer le client sur une autre machine il faut bien sur remplacer 127.0.0.1 par l’adresse IP (ou le nom d’hôte) de votre serveur.

Si on regarde le code C de ce premier serveur (./test-readme.c), on peut retrouver la pipeline GStreamer qui va s’occuper de diffuser le flux sur le réseau:

videotestsrc is-live=1 ! x264enc ! rtph264pay name=pay0 pt=96

On a donc la génération de la mire avec videotestsrc, puis un encodage H.264 avec x264enc puis enfant un streaming RTP avec rtph264pay.

Pour lire se genre de flux, on peut utiliser plusieurs logiciels. Le plus « populaire » est le très frenchie VLC. On lance donc le logiciel puis on va dans le menu Média / Ouvrir un flux réseau, puis on entre l’URL: rtsp://127.0.0.1:8554/test

Après quelques secondes, la vidéo devrait s’afficher:

On peut aussi utiliser FFplay (le player basée sur FFmpeg):

ffmplay rtsp://127.0.0.1:8554/test

Ou bien directement une pipeline GStreamer, ce qui ouvre la porte à des post traitements:

gst-launch -v rtspsrc location=rtsp://127.0.0.1:8554/test ! queue ! decodebin ! ffmpegcolorspace ! autovideosink

Il est bien sur possible de lancer plusieurs clients vers la même source RTSP (j’ai testé 3 clients en parallèle).

Une mire c’est bien, un fichier MPEG-4 c’est mieux

Les esprits chagrins vont me dire que pour tester les fonctions de seekink (déplacement temporel) avec une mire ce n’est pas terrible… Nous allons donc streamer une vidéo MPEG-4 (j’ai utilisé le logiciel Avidemux pour produire une vidéo de 640×360 en MPEG-4 ISO à partir d’une source Big Buck Bunny 720p AVI).

On va lancer le serveur avec les commandes suivantes (toujours dans le sous répertoires examples):

./test-mp4 ~/big_buck_bunny_360p_surround.mp4

Lecture à partir de VLC:

On a alors, pour cette vidéo, un flux réseau entre le serveur et le client variant entre 350 et 550 Kbps. Ceci est normal car la pipeline suivante que l’on peut trouver dans le fichier test-mp4.c ne fait en fait aucun transcodage. Comme la vidéo n’a pas été encodé en CBR (constant bit rate) on se retrouve avec des variations de débits:

filesrc location=%s ! qtdemux name=d d. ! queue ! rtph264pay pt=96 name=pay0 d. ! queue ! rtpmp4apay pt=97 name=pay1

Coté occupation CPU du coté client je suis à environ 25% sur un Core 2 à 1.8 Ghz.

Capture réseau

Pour les plus curieux d’entre vous, voici le résultat d’une capture réseau entre mon serveur RTSP (192.168.29.79) et un client (192.168.29.148).

On peut notamment y voir la négociation RTSP avec la liste des fonctions disponibles sur le serveur (OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET-PARAMETER, TEARDOWN) puis le début du streaming RTP.

Conclusion

Bien qu’en développement, ce projet de serveur RTSP basé sur GStreamer est très stable (je n’ai pas rencontré de plantage lors de mes tests) et facile à intégrer dans un développement en C. Si vous voulez faire mumuse et développer votre propre serveur, je vous conseille la lecture du fichier README qui se trouve dans le sous répertoire docs.

A vos serveurs !

Catégories
Open-source Video Web

Vidéos de Youtube roses sous Ubuntu ?

Si comme moi vous rentrez de vacance et qu’en ouvrant votre navigateur Web les vidéos sous Youtube ont une facheuse tendance à être affichées avec un filtre rose/rouge:

… alors ces deux petites commandes (à saisir dans un terminal) devraient résoudre votre problème:

sudo mkdir /etc/adobe

sudo bash -c « echo ‘OverrideGPUValidation = 0’ >> /etc/adobe/mms.cfg »

Il faut ensuite fermer et relancer sont navigateur pour que la modification soit prise en compte.

Pour information , ce problème vient d’un bug dans Adobe Flash 10.2 (encore lui…).

Source: WebUpd8

Catégories
Blog Open-source Web

Le panier du marché libre #7

Elle sont belles mes nouvelles, elles sont fraiches, qui veut des nouvelles !?!?!?

Et pour finir une très bonne recette: les spaghettis alla mafiosi (je sais c’est pas dans la ligne éditoriale du blog mais m’en bati sieu Nissart).

Catégories
Blog Open-source Planet-libre Reseau Systeme Web

Sécuriser son blog WordPress #4

Nous voici donc dans le dernier volet de notre saga sur la sécurisation d’un serveur Web hébergeant un blog WordPress. Si vous avez suivi les recommandations des billets précédant vous devriez  avoir un serveur avec un niveau de sécurité acceptable…

La perfection n’existant pas, du moins en sécurité informatique, il est nécessaire d’avoir sous la main les moyens de remonter rapidement votre serveur en cas de piratage.

Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #4):

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (un dernier grand merci à lui :)).

Sauvegardes régulières

En effet, quelque soit les moyens que vous aller mettre en oeuvre, votre serveur ne sera jamais protégé à 100%. Il est donc essentiel d’avoir une sauvegarde récente de l’ensemble de votre blog, c’est à dire:

  • vos fichiers statiques (images, videos, fichiers de données…)
  • votre base de donnée SQL
  • une procédure (ou encore mieux un script comme celui-ci) à jour de réinstallation de votre serveur

Voici donc le détail de ces actions.

Sauvegarde des fichiers statiques

J’effectue cette sauvegarde en deux étapes.

1) La première est un backup de l’ensemble de mon répertoire Web (contenant WordPress et les fichiers statiques) sur un deuxième disque qui est attaché à mon serveur virtuel (VPS). Ainsi en cas de crash disque, les données seront disponibles localement. Attention de bien vérifier auprès de votre hébergeur que ce deuxième disque virtuel est bien sur un disque physique différent de celui sur lequel est hébergé votre blog !

J’utilise le logiciel RSnapShot pour effectuer cette tache. J’ai rédigé un billet sur le sujet que vous pouvez consulter ici.

2) La seconde étape est de copier de manière régulière (et si possible automatique) ces sauvegardes sur une autre machine. En effet, si un méchant hackeur pirate votre serveur, il y a de fortes chances qu’il s’en prenne également à vos sauvegardes locales.

Pour cela, j’utilise le service « in the cloud » Dropbox (en attendant un service équivalent basée sur des clients libres). Pour installer et utiliser Dropbox sur un serveur sans interface graphique, vous pouvez suivre cette procédure. J’archive avec une commande tar l’ensemble du répertoire WordPress puis je le copie dans un sous répertoire de ma Dropbox.

Sauvegarde de la base de donnée SQL

J’utilise le plugin WordPress WP-DBManager qui, en plus d’optimiser automatiquement ma base de donnée,  sauvegarde et envoi une archive directement sur mon adresse mail (la fréquence des expéditions est configurable).

Il est également possible d’automatiser une commande mysqldump dans votre crontab systeme et comme les fichiers statiques copier l’archive dans une copie locale et dans votre Dropbox.

Re-installation rapide de son serveur « from scratch »

Ce point est souvent négligé, à tort !

Quoi de plus long que de ré-installer et re-configurer un serveur en production sous la pression du temps… Avoir un script qui reproduit ces étapes de configuration est plus qu’utile en cas de problème : piratage ou bien panne matérielle. En cas de piratage, il faudra évidemment chercher la cause du problème et la résoudre avant de remettre son serveur en ligne et bien entendu modifier tous les mots de passes (système, WordPress, base de donnée SQL…).

Maintenance et supervision

Dans la première partie de cette série de billets, nous avons installé le logiciel cron-apt qui envoie automatiquement un mail quand des mises à jour son disponible pour votre serveur. Il faut bien sûr prendre le temps de lire ces mails et de les traiter le cas échéant.

On peut également installer le logiciel log-watch qui surveiller pour vous les fichiers de log et envoyer automatiquement un rapport par mail. J’ai personnellement laissé tombé ce type de logiciel sur mon serveur personnel car la quantité des informations remontées nécessitait trop de temps pour être interprétée . Dans le même ordre d’idée il y a également logcheck qui permet de recevoir un rapport toutes les heures sur les lignes « anormales » trouvées dans les logs.

aptitude install logcheck

Le fichier de configuration se trouve dans /etc/logcheck/logcheck.conf. La liste des fichiers de log à surveiller dans /etc/logcheck/logcheck.logfiles.

Il faut également surveiller les rootkit (petit programme permettant d’obtenir les droits d’administration de votre serveur en se basant sur des failles connues). Pour cela il faut installer un détecteur de rootkit comme  chkrootkit:

sudo aptitude install chkrootkit

Puis le lancer régulièrement (le plus simple est de le faire par crontab et d’envoyer le résultat par mail).

sudo chkrootkit

A noter que dans la version actuelle de chkrootkit (0.49). Un faux positif est détecté sous Ubuntu 10.04 LTS dans le fichier /etc/init:

Searching for Suckit rootkit… Warning: /sbin/init INFECTED

Le message est donc à ignorer jusqu’à la prochaine mise à jour.

Pour conclure ce chapitre quelques logiciels que l’on peut installer:

  • tmpreaper : vider le /tmp régulièrement
  • vérifier l’intégrité des fichiers systèmes avec Samhain (disponible dans les dépots Ubuntu).

Conclusion

Vous l’aurez compris, sécurisé son système prend du temps, consomme des performances non négligeables et demande des connaissances approfondies. C’est néanmoins une étape fondamentale pour se protéger des pirates et autres scripts automatisés qui se feront une joie de rentrer dans votre site web ou pire, votre serveur.

Les applications présentées devraient néanmoins vous permettre de limiter la casse, mais gardez à l’esprit que la plupart des attaques se faisant via votre site web, le protéger correctement reste une des meilleurs solutions existantes.

/etc/logcheck/logcheck.conf