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

Installation complète de GStreamer sous Fedora 14

Gstreamer est un framework multimedia très puissant que j’aborde régulièrement sur mon blog (voir la liste des articles ici). Il fonctionne avec un système de « plugins » lui permettant d’apporter de nouvelles fonctions sans toucher au coeur du framework.

Comme toutes les distributions GNU/Linux, Fedora est installée par défaut avec GStreamer et un certain nombre de plugins (environ 180 sur ma toute fraîche Fedora 14).   Nous allons donc voir dans ce billet comment installer « la totale » (c’est à dire la liste complète des plugins pour GStreamer).

Installation des dépôts

J’utilise les depôts RPMFusion qui contienne les dernières versions stable de GStreamer et des plugins:

su –

yum -y localinstall –nogpgcheck http://fr2.rpmfind.net/linux/rpmfusion/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://fr2.rpmfind.net/linux/rpmfusion/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

yum update

Installation de GStreamer et de tous les composants

Cette installation devrait occuper environ 160 Mo sur votre disque dur.

LISTE=`yum -q list available ‘*gstreamer*’ | awk ‘{print $1 }’ | grep gstreamer | xargs -eol` ; yum -y install $LISTE

A la fin de cette installation, on peut demander le nombre de plugins avec la commande suivantes:

gst-inspect | tail -1

Nombre total :229 greffons (2 éléments de liste noire not shown), 1125 fonctionnalités

Et voili, on a donc un gain de 49 plugins 🙂 !

Catégories
Image Open-source Planet-libre Systeme

Mon desktop 201011

Comme chaque début de mois, voici une actualisation de mon desktop (sous Ubuntu 10.10) qui va m’accompagner en novembre 2011 !

On commence par le résultat:

Fond d’écran: Urban Digital sur DevianArt
GTKLook des fenêtre Equinoxicônes Faenza
Sur ce bureau: Terminator (Htop) + Nautilus Elementary

Installation des dépôts

On lance un terminal et on saisie les lignes de commandes suivantes:

sudo add-apt-repository ppa:tiheum/equinox

sudo add-apt-repository ppa:am-monkeyd/nautilus-elementary-ppa

sudo aptitude update

sudo aptitude safe-upgrade

Installer de la combo magique (Equinox + Faenza + Nautilus Elementary)

Puis on installe le thème:

sudo aptitude install gtk2-engines-equinox equinox-theme equinox-ubuntu-theme faenza-icon-theme

nautilus -q

On active le tout en allant dans le menu “Système > Préférences > Apparences > Thème > Equinox Evolution“.

Installation de Docky

Ce dock « à la MacOS X »  est disponible dans les dépôt standard, pour l’installer en ligne de commande:

sudo aptitude install docky

Pour le paramétrage, j’utilise:

Paramétrage de mon tableau de bord

J’utilise l’application NetSpeed pour voir en temps réel les débits sur mon interface réseau. Il faut l’installer avec la ligne de commande suivante:

sudo aptitude install netspeed

Ensuite je configure de la manière suivante:

Et vous cela donne quoi vos desktops en ce moment, à vos screenshots !

Catégories
Developpement Open-source Planet-libre Web

Concours Prologin 2011 !

Vous chercher à occuper ce long week-end d’automne ? Vous aimez les logiciels libres ? Vous êtes un crack en algorithmique / développement ? Alors le concours Prologin 2011 est fait pour vous !

Depuis maintenant quelques années, l’association Prologin propose de participer à son concours national d’informatique. Réservé aux étudiants de vingt ans et moins, ce concours gratuit se déroule en trois étapes: qualification sur internet, demi-finale en région et  finale à Paris !

Outre le fait de faire un peu travailler vos méninges, le concours vous permettra, si vous passez la première étape de qualification en ligne, de rencontrer « in real life » des personnes partageant, comme vous la passion de l’informatique. Vous pouvez voir sur les photos des éditions précédentes que l’ambiance est plutôt sympa !

Les vainqueurs pourront ensuite valoriser ce trophée, cela fait toujours bien dans le CV :). De nombreuses écoles d’ingénieurs suivent de près ce coucours:

En bonus, ProLogin propose un site d’entrainement ouvert à tous (c’est à dire au vieux comme moi ou aux futurs participants voulant se jauger).

Pour participer au concours Prologin 2011, suivre ce lien !

Catégories
Open-source Planet-libre Systeme

Profiter de sa Dropbox sur son serveur GNU/Linux

Depuis quelques mois, j’utilise le service Dropbox (gratuit jusqu’à 2 Go) pour sauvegarder, partager et synchroniser les fichiers entre mes différentes machines. Souhaitant pouvoir également mon serveur VPS (Ubuntu Server 10.04 LTS) dans ce « cloud » et ainsi permettre la sauvegarde de certains fichiers de mon serveur dans ma Dropbox, il a fallu que je passe outre la limitation du client Dropbox de fonctionner sans un environnement graphique (no-gui…).

Pour tester cette procédure, il faut disposer:

  • d’un compte Dropbox (même un compte gratuit suffit)
  • d’un serveur avec un accès SSH et les droits admin (j’ai validé cette procédure sur un Ubuntu Server 10.04 LTS mais elle doit fonctionner sur d’autre distribution avec quelques adaptations)

Installation du daemon Dropbox

On commence par récupérer le daemon GNU/linux Dropbox sur notre serveur:

cd

wget -O ~/dropbox.tar.gz http://www.dropbox.com/download/?plat=lnx.x86

tar zxvf dropbox.tar.gz

rm -f ~/dropbox.tar.gz

L’archive va être décompressé dans le répertoire ~/.dropbox-dist. Il faut ensuite lancer le programme dropboxd qui va permettre d’associer votre serveur avec votre compte Dropbox.

.dropbox-dist/dropboxd

This client is not linked to any account…

Please visit https://www.dropbox.com/cli_link?host_id=c241bed09af0ae77383c4d89310b08cf to link this machine.

Il faut donc lancer un navigateur Web (depuis votre PC) puis visiter l’URL précédente.

Il se peut que le message suivant s’affiche:

/bin/sh: xdg-open: not found

Il n’a aucun impact sur le bon fonctionnement du daemon dropboxd.

Le programme va ensuite créer votre répertoire ~/Dropbox et y copier le contenu de votre Dropbox (personnellement, j’ai déplacé le répertoire Dropbox vers un disque virtuel attaché à mon VPS puis j’ai créé un lien symbolique entre ce répertoire et mon répertoire ~/Dropbox). Il va également générer un répertoire ~/.dropbox avec un cache et des informations sur votre compte Dropbox.

Une fois terminé, on peut ensuite quitter le programme d’installation avec un CTRL-C.

Automatisation du lancement de Dropbox

On commence par récupérer le script suivant:

http://wiki.dropbox.com/TipsAndTricks/TextBasedLinuxInstall/UbuntuStartup

Ensuite on fait un copier/coller du script dans le fichier /etc/init.d/dropbox . On édite ce fichier et on change la première ligne en mettant la liste des utilisateurs Dropbox sur notre serveur. Par exemple, pour un seul utilisateur nommé nicolargo:

DROPBOX_USERS= »nicolargo »

Puis on change les propriétés du fichier:

sudo chmod a+rx /etc/init.d/dropbox

Et on automatise le lancement:

sudo update-rc.d dropbox defaults

Enfin on essaye une séquence stop / startpour vérifier que le script fonctionne correctement:

/etc/init.d/dropbox stop

Stopping dropbox…

/etc/init.d/dropbox status

dropboxd for USER nicolargo: not running.

/etc/init.d/dropbox stop

Stopping dropbox…

/etc/init.d/dropbox status

dropboxd for USER nicolargo: running (pid 10996)

Test de la Dropbox

Le plus simple est de copier un fichier dans le répertoire ~/Dropbox et de voir si il est bien copié dans votre Dropbox (attendre quelques secondes/minutes selon la taille de votre fichier)…

touch ~/fichiertest.txt

… à l’inverse, si vous supprimé ce fichier de votre Dropbox, il devrait également être supprimé de votre répertoire ~/Dropbox.

Sur mon serveur VPS Gandi, cela marche du tonnerre 🙂

Aller plus loin avec la ligne de commande

Dropbox propose un script en Python (sous licence libre GPL v3) permettant d’administrer sa Dropbox à partir de la ligne de commande cotre serveur. Pour récupérer et installer la dernière version du script, il faut saisir les commandes suivantes:

cd

wget -O dropbox.py http://www.dropbox.com/download?dl=packages/dropbox.py

chmod a+rx dropbox.py

sudo mv dropbox.py /usr/local/bin/

On lance le script sans paramètre pour voir la liste des fonctions disponibles:

/usr/local/bin/dropbox.py

Dropbox command-line interface

commands:

status       get current status of the dropboxd

help         provide help

puburl       get public url of a file in your dropbox

filestatus   get current sync status of one or more files

ls           list directory contents with current sync status

Les plus intéressantes:

dropbox.py status: affiche ce que le daemon Dropbox est en train de faire (exemple: « Downloading 62 files (630.8 KB/sec, 1 hr left) »).

dropbox.py  puburl ~/Dropbox/Public/conky-faenza-nicolargo.tar.gz: affiche l’URL publique de votre fichier.

Maintenir le bouzin à jour

Rien de bien compliqué, une fois la configuration faite, elle restera en mémoire même en cas de mise à jour. La séquence de commande suivante devrait faire l’affaire:

sudo /etc/init.d/dropbox stop

cd

wget -O ~/dropbox.tar.gz http://www.dropbox.com/download/?plat=lnx.x86

tar zxvf dropbox.tar.gz

rm -f ~/dropbox.tar.gz

sudo /etc/init.d/dropbox start

wget -O dropbox.py http://www.dropbox.com/download?dl=packages/dropbox.py

chmod a+rx dropbox.py

sudo mv dropbox.py /usr/local/bin/

Des remarques, questions ? Les commentaires sont là pour ça !

Sources utilisées pour la rédaction de ce billet:

Catégories
Open-source

BitTorrent – Les liens vers les ISO Ubuntu

Ceci est un petit billet à usage interne pour retrouver rapidement les liens torrents des dernières distributions Ubuntu. Je maintiendrai donc ce billet à jour à chaque publication d’une nouvelle version d’Ubuntu.

Pour rappel il faut distinguer chez Ubuntu les « releases » standards (support de 2 ans) des « releases » LTS (Long Time Support – support de 3 ans pour les versions Desktop et 5 ans pour les versions Server).

Je conseille d’utiliser les versions standards pour les PC Desktop/Netbook et les versions LTS pour les serveurs.

Tableau mis à jour en avril 2012

Distribution Architecture Version Lien téléchargement
Ubuntu Desktop 32 bits 12.04 LTS Torrent
Ubuntu Desktop 64 bits 12.04 LTS Torrent
Ubuntu Alternate 32 bits 12.04 LTS Torrent
Ubuntu Alternate 64 bits 12.04 LTS Torrent
Ubuntu Server 32 bits 12.04 LTS Torrent
Ubuntu Server 64 bits 12.04 LTS Torrent
Catégories
Open-source Planet-libre Systeme

8 choses à faire après l’installation d’Ubuntu

Nous allons dans ce billet partager une petite « todo list » des actions que  j’effectue après avoir installé une distribution GNU/Linux Ubuntu Desktop. Cette liste est personnelle et me permet d’avoir un environnement de travail qui corresponde à mes besoins. Je compte sur vous pour ajouter vos commentaires et nous faire découvrir de nouvelles choses.

La connaissance s’accroît quand on la partage…

1_  Lancement du script UbuntupostInstall.sh

Ce script shell à pour but d’automatiser toutes une série d’actions que je fais plus ou moins systématiquement quand j’installe un PC sous Ubuntu Desktop. C’est la première chose que je fais sur un nouveau PC.

On peut notamment citer:

  • Ajout de dépôts pour avoir de nouveaux logiciels ou des versions plus récentes.
  • Installation d’applications indispensable à mes yeux et non présente dans la distribution de base.
  • Configuration système standard.
  • Voir un liste des actions ici

2_ De belles fenêtres, de beaux icônes

Le script précédant installe la configuration GTK suivante: Look des fenêtre Equinox et icônes Faenza.

Il faut les activer en allant dans le menu “Système > Préférences > Apparences > Thème > Equinox Evolution“.

3_ Un menu dock comme sous Mac OS X

J’utilise depuis quelques jours Docky et je dois avouer qu’après un début difficile je commence à y prendre goût… Voici mon paramétrage:

et un aperçu de la bête:

4_ Des informations directement sur votre bureau

Mon coté geek fait que j’aime bien connaître ce qui se passe dans ma bécane: son occupation CPU, mémoire, la place disponible sur le disque, les débits réseau, le nom de la musique que je suis en train d’écouter…

Pour cela j’utilise Conky avec la configuration suivante (télécharger mon fichier .conkyrc puis l’adapter à votre configuration):

5_ Configurer le tableau de bord

Rien de très original de ce coté, j’utilise un seul tableau de bord ou l’essentiel des éléments se trouvent en haut à droite de mon écran:

J’utilise l’application me permettant d’avoir un aperçu de mes 2 bureaux virtuels (plus de 2 et je n’arrive pas à m’en sortir :)).

6_ Un beau fond d’écran

Je maintien une base d’environ 70 fond d’écran que je puise dans différentes sources. Par exemple, mon fond d’écran du moment (que je change tout les mois) est disponible ici.

7_ Gestion des mes fichiers personnels

J’utilise le service Dropbox pour sauvegarder et synchroniser mes documents entre mes différentes machines (2 PC GNU/Linux, 1 MBP, 1 iPhone).

Pour adapter la Dropbox à mon environnement GNU/Linux, je fais des liens symboliques entre le répertoire ~/Dropbox et les répertoires systèmes suivants:

bin -> ../bin/: Mes scripts shells

dev -> ../dev/: Le répertoire contenant mes développements en cours

Documents -> ../Documents/: Mes documents persos

Images -> ../Images/: Mes images, photos persos

8_ Mes applications de tous les jours…

J’utilise Docky pour avoir un accès rapide aux applications suivantes:

A vous de nous faire découvrir votre monde !

Catégories
Blog Open-source Planet-libre Web

Bye bye Pino. Hello Hotot.

Dans la grande « mouvance » du Web 2.0, les systèmes de micro-blogging sont pour moi la réelle révolution pour diffuser et récolter des information.s Tout autant que mes flux RSS, mes comptes Twitter (@nicolargo) et Identi.ca forment une source constante d’informations.

A mes débuts sur Twitter (juillet 2007 :), putain 3 ans…), j’utilisais exclusivement l’interface Web Twitter, puis sont arrivés les clients de micro-blogging sous GNU/Linux avec en tête Gwibber (le client officiel sous Gnome). Après l’excitation de la nouveauté, je me suis vite rendu compte de la lourdeur et de ses bugs récurrents de ce logiciel (surtout si vous avez une version GNU/Linux non Anglaise…).

J’ai alors découvert Pino, un vrai bonheur ! Un client simple, léger, bien intégré à ma distribution Ubuntu. Je l’ai encore intégré à mon processus de publication interne. Malheureusement, début septembre 2010, Twitter décide de migrer son système d’authentification vers OAuth (un protocole ouvert). Et là patatra… A ce jour et malgré une bidouille pour permettre une authentification à Twitter par un site tiers, l’auteur de Pino n’a toujours pas fait évoluer son logiciel dans la fameuse version 0.3 sensée corriger le problème. De plus les premiers échos de cette nouvelle version ne sont pas très positifs (interface plus lourde notamment).

J’ai donc décidé d’utiliser un troisième client en lieu et place de Pino. Ce client s’appelle Hotot et il est développé par une équipe asiatique  très réactive. En plus du support de Twitter et d’Identi.ca (moyennant une petite configuration dans les menus), il promet une gestion multi-timelines (c’est à dire un mix de vos différents comptes) dans une prochaine version. Visuellement Hotot apporte son lot d’améliorations par un système de plugins (comme l’affichage des images en preview).

Update

Hotot vient juste d’être mis à jour (suite à la lecture de ce billet??? :)): support Identi.ca et multi-timelines !!!

A installer à partir des PPAs.

/Update

En attendant la suite, je choisi pour l’instant Hotot !

Et vous ?

Catégories
Blog Open-source Planet-libre Web

Booster votre site n’est pas qu’un truc de geek

Depuis la généralisation des accès hauts débits sur Internet, la rapidité de chargement d’un site est devenu un critère important à prendre en compte dès la phase de conception.

Les moteurs de recherche (Google, Yahoo, Bing…) incluent dans leurs algorithmes la vitesse d’affichage de votre site. Ainsi, Google considère qu’une page est lente si elle met plus de 4.97 secondes pour se charger. La rapidité de chargement aura donc un impact plus ou moins important (difficile d’avoir des chiffres précis) sur le référencement de votre site.

Une étude a montrée qu’un utilisateur venant sur votre site à partir d’un moteur de recherche aura une patience d’environ 4 secondes. Au delà de cette valeur le taux d’abandon devient important.

Bref, vous l’avez compris, le temps de chargement des pages est un paramètre tout aussi important que le design quand vous mettez un site en ligne.

Je me suis penché sur ce sujet lors de conception de la nouvelle version du blog de Nicolargo. Il en ressort quelques billets ciblés sur les problèmatiques de performances des blogs WordPress (basée sur des solutions libres bien sûr :)):

Au niveau des outils de tests, le Web fourmille de service en ligne. Attention lorsque vous faite vos tests de choisir des URL représentatives (pas seulement un test sur votre Home page qui ne représente que 1% de vos visiteurs…). Personnellement, j’utilise surtout:

  • GTMetrix qui permet d’automatiser le test de votre site en calculant automatiquement les valeurs Y-Slow, Page Speed.
  • WebWait: très utile pour tester les modifications que vous faites sur votre site et en mesurer l’impact en terme de vitesse de chargement.
  • Apache Benchmark (ab pour les intimes): un outil libre sous licence Apache permettant de tester la montée en charge de votre site (c’est à dire comment votre site va réagir quand beaucoup d’utilisateurs vont le consulter simultanément). Un exemple de ligne de commande que j’utilise en local sur mon serveur:

ab -t 30 -c 5 https://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html

Requests per second:    578.10 [#/sec] (mean)

Time per request:       8.649 [ms] (mean)

Time per request:       1.730 [ms] (mean, across all concurrent requests)

Transfer rate:          329.82 [Kbytes/sec] received

Et vous blogueurs, webmasters, comment prenez-vous en compte la problématique de rapidité d’affichage de vos pages ?

Catégories
Open-source Planet-libre Web

Booster votre blog WordPress avec Varnish

Varnish est un accélérateur de sites Web fonctionnant sur le principe d’un reverse proxy. Varnish va prendre en charge les requêtes HTTP venant de vos visiteurs et communiquer avec votre serveur Web en ne demandant la création des pages Web seulement quand cela est nécessaire.

C’est un projet open-source sous licence FreeBSD.

Installation

Sur un Ubuntu Server (ou une distribution Debian « like »), l’installation se résume à la commande suivante. Vous aurez ainsi la version standard maintenu par les dépôts:

sudo aptitude install varnish

Pour disposer d’une version plus récente et seulement sous Ubuntu, vous pouvez utiliser les lignes de commande suivantes:

curl http://repo.varnish-cache.org/debian/GPG-key.txt | sudo apt-key add –

sudo echo « deb http://repo.varnish-cache.org/ubuntu/ $(lsb_release -s -c) varnish-2.1 » >> /etc/apt/sources.list

sudo aptitude update

sudo aptitude  install varnish

Nous allons donc dans un premier temps tester Varnish sur la configuration initiale de notre serveur Web (qui comprend dans mon exemple deux sites virtuels sous Apache). Cette configuration de test permettra de tester les performances de Varnish sans aucun impact sur vos sites (les visiteurs continueront à passer directement par votre serveur Web Apache). Enfin, si les tests sont concluants, nous modifierons la configuration finale pour que vos visiteurs transitent de manière transparente par Varnish.

Configuration de test

Varnish appelle backend les serveurs Web qu’il doit accélérer. Il est possible de définir un ou plusieurs backends par serveur Varnish.

Ainsi, si l’on souhaite accélérer le site https://blog.nicolargo.com qui est hébérgé sur un serveur, il faut saisir la configuration suivante dans le fichier /etc/varnish/default.vcl (configuration librement inspiré de la documentation officielle sur comment optimiser son blog WordPress avec Varnish) avec une gestion du cache sur les requête POST, pas de cache pour la zone admin, gestion des cookies de Google Analytics.

Vous pouvez télécharger la configuration Varnish VCL complète pour WordPress ici.

#

# Varnish 3 configuration for WordPress

#

# On Debian OS: /etc/varnish/default.vcl

#

# Nicolas Hennion (aka) Nicolargo

#

# Set the default backend (Nginx server for me)

backend default {

# My Nginx server listen on IP address 127.0.0.1 and TCP port 8080

.host = "127.0.0.1";

.port = "8080";

# Increase guru timeout

# http://vincentfretin.ecreall.com/articles/varnish-guru-meditation-on-timeout

.first_byte_timeout = 300s;

}

# Forbidden IP ACL

acl forbidden {

"41.194.61.2"/32;

"192.54.144.229"/32;

}

# Purge ACL

acl purge {

# Only localhost can purge my cache

"127.0.0.1";

"localhost";

}

# This function is used when a request is send by a HTTP client (Browser)

sub vcl_recv {

# Block the forbidden IP addresse

if (client.ip ~ forbidden) {

error 403 "Forbidden";

}

# Only cache the following sites

#if ((req.http.host ~ "(blog.nicolargo.com)") || (req.http.host ~ "(blogtest.nicolargo.com)")) {

if ((req.http.host ~ "(blog.nicolargo.com)")) {

set req.backend = default;

} else {

return (pass);

}

# Compatibility with Apache format log

if (req.restarts == 0) {

if (req.http.x-forwarded-for) {

set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip;

} else {

set req.http.X-Forwarded-For = client.ip;

}

}

# Normalize the header, remove the port (in case you're testing this on various TCP ports)

set req.http.Host = regsub(req.http.Host, ":[0-9]+", "");

# Allow purging from ACL

if (req.request == "PURGE") {

# If not allowed then a error 405 is returned

if (!client.ip ~ purge) {

error 405 "This IP is not allowed to send PURGE requests.";

}

# If allowed, do a cache_lookup -> vlc_hit() or vlc_miss()

return (lookup);

}

# Post requests will not be cached

if (req.request == "POST") {

return (pass);

}

# --- WordPress specific configuration

# Did not cache the RSS feed

if (req.url ~ "/feed") {

return (pass);

}

# Blitz hack

if (req.url ~ "/mu-.*") {

return (pass);

}

# Did not cache the admin and login pages

if (req.url ~ "/wp-(login|admin)") {

return (pass);

}

# Remove the "has_js" cookie

set req.http.Cookie = regsuball(req.http.Cookie, "has_js=[^;]+(; )?", "");

# Remove any Google Analytics based cookies

set req.http.Cookie = regsuball(req.http.Cookie, "__utm.=[^;]+(; )?", "");

# Remove the Quant Capital cookies (added by some plugin, all __qca)

set req.http.Cookie = regsuball(req.http.Cookie, "__qc.=[^;]+(; )?", "");

# Remove the wp-settings-1 cookie

set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-1=[^;]+(; )?", "");

# Remove the wp-settings-time-1 cookie

set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-time-1=[^;]+(; )?", "");

# Remove the wp test cookie

set req.http.Cookie = regsuball(req.http.Cookie, "wordpress_test_cookie=[^;]+(; )?", "");

# Are there cookies left with only spaces or that are empty?

if (req.http.cookie ~ "^ *$") {

unset req.http.cookie;

}

# Cache the following files extensions

if (req.url ~ "\.(css|js|png|gif|jp(e)?g|swf|ico)") {

unset req.http.cookie;

}

# Normalize Accept-Encoding header and compression

# https://www.varnish-cache.org/docs/3.0/tutorial/vary.html

if (req.http.Accept-Encoding) {

# Do no compress compressed files...

if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|tbz|mp3|ogg)$") {

remove req.http.Accept-Encoding;

} elsif (req.http.Accept-Encoding ~ "gzip") {

set req.http.Accept-Encoding = "gzip";

} elsif (req.http.Accept-Encoding ~ "deflate") {

set req.http.Accept-Encoding = "deflate";

} else {

remove req.http.Accept-Encoding;

}

}

# Check the cookies for wordpress-specific items

if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~ "comment_") {

return (pass);

}

if (!req.http.cookie) {

unset req.http.cookie;

}

# --- End of WordPress specific configuration

# Did not cache HTTP authentication and HTTP Cookie

if (req.http.Authorization || req.http.Cookie) {

# Not cacheable by default

return (pass);

}

# Cache all others requests

return (lookup);

}

sub vcl_pipe {

return (pipe);

}

sub vcl_pass {

return (pass);

}

# The data on which the hashing will take place

sub vcl_hash {

hash_data(req.url);

if (req.http.host) {

hash_data(req.http.host);

} else {

hash_data(server.ip);

}

# If the client supports compression, keep that in a different cache

if (req.http.Accept-Encoding) {

hash_data(req.http.Accept-Encoding);

}

return (hash);

}

sub vcl_hit {

# Allow purges

if (req.request == "PURGE") {

purge;

error 200 "Purged.";

}

return (deliver);

}

sub vcl_miss {

# Allow purges

if (req.request == "PURGE") {

purge;

error 200 "Purged.";

}

return (fetch);

}

# This function is used when a request is sent by our backend (Nginx server)

sub vcl_fetch {

# For static content strip all backend cookies

if (req.url ~ "\.(css|js|png|gif|jp(e?)g)|swf|ico") {

unset beresp.http.cookie;

}

# A TTL of 30 minutes

set beresp.ttl = 1800s;

return (deliver);

}

# The routine when we deliver the HTTP request to the user

# Last chance to modify headers that are sent to the client

sub vcl_deliver {

if (obj.hits > 0) {

set resp.http.X-Cache = "cached";

} else {

set resp.http.x-Cache = "uncached";

}

# Remove some headers: PHP version

unset resp.http.X-Powered-By;

# Remove some headers: Apache version & OS

unset resp.http.Server;

return (deliver);

}

sub vcl_init {

return (ok);

}

sub vcl_fini {

return (ok);

}

Le port d’écoute par défaut de Varnish est  TCP/6081 (défini dans le fichier /etc/default/varnish).

Si vous avez un Firewall (iptables) sur votre serveur, il faut penser à ajouter la règle suivante:

iptables -A OUTPUT -p tcp –dport 6081 -j ACCEPT

On relance Varnish pour prendre en compte la configuration:

sudo service varnish restart

Si tout marche bien, vos sites doivent s’afficher avec les URL: http://www.nicolargo.com:6081 et https://blog.nicolargo.com:6081 (à remplacer par vos sites hein, faite pas les boulets…).

Tests sur le site statique

Test local sur le site statique (avec uniquement des éléments statiques page HTML & images). La configuration donnée ci-dessous ne montre pas l’optimisation pour ce site.

Test sur une page statique (HTML simple) sans Varnish:

ab -t 30 -c 5 http://www.nicolargo.com/

Requests per second:    651 [#/sec] (mean)

Time per request:       7.6 [ms] (mean)

Test sur une page statique (HTML simple) avec Varnish:

ab -t 30 -c 5 http://www.nicolargo.com:6081/

Requests per second:    652 [#/sec] (mean)

Time per request:       7.6 [ms] (mean)

Sur notre site Web statique, on n’a donc pas de gain au niveau de la capacité maximale de montée en charge du serveur Apache (Requests per second). Ce qui est normal vu qu’Apache n’a pas grand chose à faire pour servir ce genre de page. Par contre on observe une occupation mémoire moindre pendant le test avec Varnish (environ 10% de moins).

Tests sur le site dynamique (WordPress)

Test en local sur le site Web dynamique (WordPress, déjà optimisé en suivant ce tutoriel).

Test sur la page index d’un blog WordPress sans Varnish:

ab -t 30 -c 5 https://blog.nicolargo.com/

Requests per second:    588 [#/sec] (mean)

Time per request:       8.5 [ms] (mean)

Test sur la page index d’un blog WordPress avec Varnish:

ab -t 30 -c 5 https://blog.nicolargo.com:6081/

Requests per second:    3460 [#/sec] (mean)

Time per request:       1.5 [ms] (mean)

Sur notre site dynamique, la valeur ajoutée de Varnish est importante car on a ici un gain de plus de 488% en terme de nombre de requêtes simultanées que votre serveur peut fournir. Sur une page dynamique un peu plus lourde (par exemple un billet avec beaucoup de commentaires), le gain peut alors monter jusqu’à 650%.

Attention, cela ne veut pas dire que votre blog va s’afficher 488% plus vite avec Varnish mais « seulement » que votre serveur pourra accepter 488% de requêtes simultanées maximales en plus.

Configuration finale

Une fois votre site accéléré validé, il faut passer Varnish en production. Les actions suivantes sont à effectuer.

Configurer le serveur Apache hébergeant votre blog pour écouter sur un port différent du port TCP/80 (par exemple TCP/8080). Sous Ubuntu Server, on commence par modifier le fichier /etc/apache2/ports.conf pour lui demander d’écouter les requêtes HTTP sur le port 8080 en lieu et place du port 80:

NameVirtualHost *:8080

Listen 8080

On modifie ensuite le fichier de configuration de nos sites /etc/apache2/site-enabled/virtualhosts: (notez bien la modification du port :8080 et l’utilisation du format de log varnishcombined)

# WWW

<VirtualHost *:8080>

DocumentRoot /var/www/www

ServerName nicolargo.com

ServerAlias www.nicolargo.com

ServerAdmin contact@pasdespam.com

CustomLog /var/log/apache2/www-access.log varnishcombined

ErrorLog /var/log/apache2/www-error.log

</VirtualHost>

# BLOG

<VirtualHost *:8080>

DocumentRoot /var/www/blog

ServerName blog.nicolargo.com

ServerAdmin contact@pasdespam.com

CustomLog /var/log/apache2/blog-access.log varnishcombined

ErrorLog /var/log/apache2/blog-error.log

</VirtualHost>

On configurer le serveur Apache pour loguer les adresses sources et non pas l’adresse du serveur Varnish. Il suffit pour cela d’ajouter la ligne suivante dans le fichier /etc/apache2/apache2.conf:

LogFormat « %{X-Forwarded-For}i %l %u %t \ »%r\ » %>s %b \ »%{Referer}i\ » \ »%{User-Agent}i\ » » varnishcombined

La configuration d’Apache est maintenant fini, il faut alors configurer Varnish pour écouter sur le port TCP/80 et changer la configuration du « backend » en éditant la section suivante du fichier /etc/default/varnish:

DAEMON_OPTS= »-a :80 \

-T localhost:6082 \

-f /etc/varnish/default.vcl \

-S /etc/varnish/secret \

-p thread_pool_add_delay=2 \

-p thread_pools=4 \

-p thread_pool_min=200 \

-p thread_pool_max=4000 \

-p cli_timeout=25 \

-p session_linger=100 \

-s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1G »

On change ensuite la configuration de Varnish pour pointer les backends vers le port 8080:

backend blog {

.host = « blog.nicolargo.com »;

.port = « 8080 »;

}

La dernière chose à faire si votre serveur est protégé par un Firewall IpTables est de modifier la règle ajoutée dans le premier chapitre de ce billet et d’y ajouter une nouvelle règle pour une éventuelle administration locale de Varnish à l’aide de l’utilitaire varnishadm:

iptables -A OUTPUT -p tcp –dport 8080 -j ACCEPT

iptables -A OUTPUT -p tcp –dport 6082 -s 127.0.0.1 -j ACCEPT

On prend en compte la configuration finale en relancant les deux processus (Apache et Varnish):

sudo service apache2 restart

sudo service varnish restart

A partir de ce moment là, toutes les requêtes HTTP de vos visiteurs seront d’abord prise en compte par Varnish (sur le port TCP/80) puis ensuite, si nécessaire, par votre serveur Apache (TCP/8080).

Ecrire les logs sur le disque

Update du 22/02/2012

Par défaut, Varnish n’écrit pas les logs dans un fichier. Pour forcer Varnish à générer des fichiers de logs au format NSCA dans le sous répertoire /var/log/varnishnsca, nous allons utiliser le daemon VarnishNSCA (installé en même temps que Varnish). Il faut commencer par vérifier que script de lancement du daemon VarnishNSCA (/etc/init.d/varnishnsca) ne contient pas un bug, comme c’est le cas dans ma version 3.0.2:

Remplacer la ligne suivante dans le fichier /etc/init.d/varnishnsca:

DAEMON_OPTS= »-a -w ${LOGFILE} -D -P $PIDFILE} »

par

DAEMON_OPTS= »-a -w ${LOGFILE} -D -P ${PIDFILE} »

Puis forcer le lancement du daemon en modifiant le fichier /etc/default/varnishnsca:

VARNISHNCSA_ENABLED=1

On peut ensuite lancer le daemon:

sudo service varnishnsca start

Il est alors possible d’analyser ce fichier avec vos outils de stats favoris. Par exemple en ligne de commande avec GoAccess:

goaccess -f /var/log/varnish/varnishncsa.log

Quelques commandes utiles

  • varnishlog: Affichage du log du daemon Varnish.
  • varnishstat: Affichage des statistiques d’utilisation de Varnish.
  • varnishhist: Affiche un historique sous forme de graphe des requêtes faites à votre serveur Varnish.
  • varnishadm: une interface d’administration locale de Varnish

Vous pouvez également consulter la documentation en ligne à l’adresse suivante.

Catégories
Nagios Open-source Planet-libre

Nagios Core 3.2.3 est disponible, les scripts de Nicolargo aussi !

Nagios vient de mettre à jour le coeur de son système de supervision en passante en version 3.2.3 avec quelques corrections de bugs au programme.

En parallèle j’ai modifié les scripts d’installation et de mise à jour de Nagios pour qu’il prenne en compte cette nouvelle version.

Si vous avez suivi mon tutoriel d’installation de Nagios (ou que vous avez utilisé le script), il suffit de saisir les commande suivantes pour effectuer une mise à jour de votre serveur:

rm -f nagiosautoupdate-ubuntu.sh

wget https://raw.github.com/nicolargo/nagiosautoinstall/master/nagiosautoupdate-ubuntu.sh

chmod a+x nagiosautoupdate-ubuntu.sh

sudo ./nagiosautoupdate-ubuntu.sh

Attention: cette méthode de mise à jour ne fonctionnera pas si vous avez installé Nagios à partir des dépôts officiels de votre distribution.

Et hop !