Archive for mai, 2011

Installer nagios sur Fedora 11 depuis les sources

Capture Nagios Alex On considère que le serveur tourne, que apache est déjà installé et que le port 80 est ouvert, http://votre_serveur affiche une page web. Je pars sur une Fedora 11, car c’est un serveur que j’ai disponible et son rôle actuel me permet d’y ajouter Nagios pour une tâche de monitoring.

Je suis root sur le serveur, connecté en SSH.

1 – télécharger et décompresser les sources
[bash]wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.3.tar.gz
tar xvzf nagios-3.2.3.tar.gz
cd nagios-3.2.3[/bash]

2 – ajouter le user nagios sur le serveur
[bash]adduser nagios
groupadd nagios[/bash]

3 – installer les dépendances
[bash]yum install gd gd-devel mod_perl jpeg-devel rrdtools-devel rrd rrdtool-devel fping net-snmp-perl perl-Net-ARP openldap-devel mysql-devel gnutls-devel radiusclient-ng-devel[/bash]

4 – Configurer et compiler Nagios
[bash]./configure –with-nagios-user=nagios –with-nagios-group=nagios
make all[/bash]

Le résultat doit afficher :
[bash]If the main program and CGIs compiled without any errors, you
can continue with installing Nagios as follows (type ‘make’
without any arguments for a list of all possible options):

make install
– This installs the main program, CGIs, and HTML files

make install-init
– This installs the init script in /etc/rc.d/init.d

make install-commandmode
– This installs and configures permissions on the
directory for holding the external command file

make install-config
– This installs *SAMPLE* config files in /usr/local/nagios/etc
You’ll have to modify these sample files before you can
use Nagios. Read the HTML documentation for more info
on doing this. Pay particular attention to the docs on
object configuration files, as they determine what/how
things get monitored!

make install-webconf
– This installs the Apache config file for the Nagios
web interface

*** Support Notes *******************************************

If you have questions about configuring or running Nagios,
please make sure that you:

– Look at the sample config files
– Read the HTML documentation
– Read the FAQs online at http://www.nagios.org/faqs

before you post a question to one of the mailing lists.
Also make sure to include pertinent information that could
help others help you. This might include:

– What version of Nagios you are using
– What version of the plugins you are using
– Relevant snippets from your config files
– Relevant error messages from the Nagios log file

For more information on obtaining support for Nagios, visit:

http://www.nagios.org/support/

*************************************************************

Enjoy.[/bash]

5 – Installer chaque élément en détail :
[bash]make install
make install-init
make install-commandmode
make install-config
make install-webconf
make install-html
make install-cgis[/bash]

Configurer le mot de passe pour l’accès à l’interface :
[bash]htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin[/bash]
(Saisir le mot de passe de votre choix pour l’utilisateur nagiosadmin)

Note : s’assurer que le dossier /usr/local/nagios/sbin existe et contient bien les fichier .cgi
Note 2 : S’assurer que le dossier /usr/local/nagios/share existe et contient bien les fichiers php et dossiers images etc.

6 – faire le test de la configuration de Nagios :
[bash]/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg[/bash]

7 – Activer le lancement automatique des services au boot
[bash]chkconfig –add nagios; chkconfig nagios[/bash]
(vérifier que ça se lance bien au démarrage).

8 – Téléchargement, configuration et installation des plugins
[bash]cd ..
wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz
tar xvzf nagios-plugins-1.4.15.tar.gz
cd nagios-plugins-1.4.15
./configure –with-nagios-user=nagios –with-nagios-group=nagios
make
make install[/bash]

9 – Lancer Nagios et relancer apache et se connecter sur http://votre_serveur/nagios
[bash]/etc/rc.d/init.d/nagios restart
/etc/rc.d/init.d/httpd restat[/bash]

#########################
# CONFIGURATION DU CLIENT NRPE #
#########################
10 – Pour monitorer d’autres machines on passera par NRPE (SNMP est aussi possible, mais je ne le traite pas ici)
Les autres machines sont considérées comme « clientes », sur chacune d’elle on doit installer Nagios-plugins et NRPE.

Les plugins fournissent les scripts permettant de monitorer les services, et NRPE permet de remonter l’information au serveur Nagios précédemment installée en exécutant ces scripts.

10.1 – Création de l’utilisateur et du groupe nagios sur la machine cliente qui va être équipée de NRPE
[bash]adduser nagios
groupadd nagios[/bash]

10.2 Installation des dépendances, comme pour le serveur (en root également, ici aussi une fedora):
[bash]yum install gd gd-devel mod_perl jpeg-devel rrdtools-devel rrd rrdtool-devel fping net-snmp-perl perl-Net-ARP openldap-devel mysql-devel gnutls-devel radiusclient-ng-devel net-snmp-devel[/bash]

10.3 – Téléchargement et installation des plugins nagios depuis http://www.nagios.org/download/plugins
[bash]wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz
tar xvzf nagios-plugins-1.4.15.tar.gz
cd nagios-plugins-1.4.15
./configure –with-nagios-user=nagios –with-nagios-group=nagios
make
make install[/bash]

Les plugins doivent être installés dans /usr/local/nagios/libexec/

On attribue les bon droits :
[bash]chown nagios:nagios /usr/local/nagios
chown -R nagios:nagios /usr/local/nagios/libexec[/bash]

10.4 Téléchargement et installation de NRPE depuis http://exchange.nagios.org/directory/Addons/Monitoring-Agents/NRPE-%252D-Nagios-Remote-Plugin-Executor/details

Pour les détails, l’archive contient un dossier docs avec un document PDF très bien fait :)

[bash]wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
tar xvzf nrpe-2.12.tar.gz
cd nrpe-2.12
./configure
make all
make install-plugin
make install-daemon
make install-daemon-config
cp init-script /etc/rc.d/init.d/nrpe
chmod 755 /etc/rc.d/init.d/nrpe
chkconfig –add nrpe;chkconfig nrpe[/bash]
(vérifier que le lancement soit bien actif)

On ajoute le service dans /etc/service en ajoutant au fichier dans l’ordre des ports la ligne suivante :
[bash]nrpe 5666/tcp # NRPE remote nagios[/bash]

On teste l’installation :
[bash]/usr/local/nagios/libexec/check_nrpe -H localhost[/bash]
ça doit renvoyer la version de NRPE :)

Ouvrir le firewall pour permettre au demon d’être joignable depuis une autre machine :
[bash]iptables -I RH-Firewall-1-INPUT -p tcp -m tcp –dport 5666 -j ACCEPT[/bash]
ou (selon la configuration de votre iptables)
[bash]iptables -I INPUT -p tcp -m tcp –dport 5666 -j ACCEPT[/bash]

On sauve la règle :
[bash]cp /etc/sysconfig/iptables /etc/sysconfig/iptables-avant-nrpe;iptables-save > /etc/sysconfig/iptables[/bash]

On édite la configuratoin de NRPE sur le client toujours dans le fichier /usr/local/nagios/etc/nrpe.cfg.
Le fichier est plutôt bien documenté, je suggère de le lire en entier. La ligne qui nous intéresse est :
[bash]allowed_hosts=127.0.0.1[/bash]
à laquelle il faut ajouter « ,ip_du_serveur_nagios » pour l’autoriser à communiquer avec NRPE sur cette machine.
Par défaut on va utiliser les plugins codés en dur, en bas du fichier vous pouvez en ajouter sur le modèle des plugins utilisés dans nagios habituellement (corriger le disque hda1 en sda1, ajouter une commande par copier/coller pour sda2 etc.).

Puis on relance NRPE.
[bash]/etc/rc.d/init.d/nrpe restart[/bash]

10.5 Configuration de NRPE sur la machine Nagios
On télécharge l’archive sur la machine où nous avons installé nagios :

[bash]wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
tar xvzf nrpe-2.12.tar.gz
cd nrpe-2.12
./configure
make all
make install-plugin[/bash]

On teste l’installation en local (attention à l’ouverture de port dans le firewall au besoin pour ce test)
[bash]/usr/local/nagios/libexec/check_nrpe -H localhost[/bash]
et surtout on teste l’hote distant :
[bash]/usr/local/nagios/libexec/check_nrpe -H votre_hote_distant -t 100[/bash]

Vous devez voir la version de NRPE installée en retour. En cas d’erreur, regarder les syslog sur l’autre machine et vérifier le firewall !

On peut ensuite tester les commandes spécifiques installées par défaut depuis la machine nagios sur la machine monitorée :
[bash]/usr/local/nagios/libexec/check_nrpe -H votre_hote_distant -c check_users
/usr/local/nagios/libexec/check_nrpe -H votre_hote_distant -c check_load
/usr/local/nagios/libexec/check_nrpe -H votre_hote_distant -c check_sda1
/usr/local/nagios/libexec/check_nrpe -H votre_hote_distant -c check_total_procs
/usr/local/nagios/libexec/check_nrpe -H votre_hote_distant -c check_zombie_procs[/bash]

Ceci soit renvoyer les valeurs de la machine distante.

10.6 Configuration de Nagios pour utiliser NRPE
Par défaut, l’installation de Nagios comporte une seule machine à monitorer configurée (localhost) dans un seul fichier de configuration.
Ceci est défini dans /usr/local/nagios/etc/nagios.cfg avec une ligne qui contient :

[bash]# Definitions for monitoring the local (Linux) host
cfg_file=/usr/local/nagios/etc/objects/localhost.cfg[/bash]

Un peu plus bas dans le fichier on peut définir suivant l’exemple un dossier qui sera parcouru par nagios à la recherche de tous les fichiers .cfg qui s’y trouvent, afin de pouvoir ajouter un fichier de configuration par hote.
On peut aussi définir un chemin par hote en dur comme indiqué pour la machine locale, libre choix !

On crée donc un dossier pour les machines dans lequel on placera toutes les configurations :
[bash]mkdir /usr/local/nagios/etc/machines
chown nagios:nagios /usr/local/nagios/etc/machines[/bash]

Puis on ajoute dans le fichier de configuration /usr/local/nagios/etc/nagios.cfg la ligne suivante :
[bash]cfg_dir=/usr/local/nagios/etc/machines[/bash]

Ainsi à chaque rechargement de nagios, tous les fichiers de configuration .cfg dans le dossier défini seront pris en compte.

On va maintenant ajouter la commande qui permet d’utiliser NRPE dans nagios.
Il faut ajouter ce qui suit dans le fichier /usr/local/nagios/etc/objects/commands.cfg :

[bash]#Commande utilisée pour interroger les hotes distants équipés de NRPE
define command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}[/bash]

On apprend à Nagios la commande check_nrpe ! :D

On va ensuite créer un template (modèle) de machine type, ici un modèle de machine linux que nous souhaitons surveiller.
On va ajouter ce template dans le fichier /usr/local/nagios/etc/objects/templates.cfg sous les hosts templates existant (donc juste au dessus de « SERVICE TEMPLATES » :

[bash]# Defini un modèle d’hotes que l’on va utiliser pour nos machines distantes avec nrpe.
define host{
name linux-box-distant ; Name of this template
use generic-host ; Inherit default values
check_period 24×7
check_interval 5
retry_interval 1
max_check_attempts 10
check_command check-host-alive
notification_period 24×7
notification_interval 30
notification_options d,r
contact_groups admins
register 0 ; DONT REGISTER THIS – ITS A TEMPLATE
}[/bash]
(Voir les templates existant pour adapter les valeurs à vos besoins)

On va maintenant créer un fichier de configuration machine-distante1.cfg pour notre nouvel hote dans /usr/local/nagios/etc/machines/ que nous avons créé un peu avant :)

On va mettre dans ce fichier « machine la définition de la machine :

[bash]#Definition machine à surveiller
define host{
use linux-box-distant ; Inherit default values from a template
host_name machine-distante1 ; The name we’re giving to this server
alias Serveur archives 1 ; A longer name for the server
address 192.168.0.1 ; IP address of the server
}[/bash]

Dans ce même fichier machine-distante1.cfg on va ajouter les services que l’on souhaite surveiller.
On dispore des services définis dans le fichier nrpe.cfg sur le serveur distant que l’on souhaite surveiller (les command[check…) :

[bash]#Definition des services surveillés dans la machine :
#Surveillance CPU LOAD
define service{
use generic-service ;basé sur le template qui défini generic-service
host_name machine-distante1 ;le nom du serveur distant
service_description CPU Load
check_command check_nrpe!check_load
}

#Suveillance du nombre d’utilisateurs
define service{
use generic-service
host_name machine-distante1
service_description Current Users
check_command check_nrpe!check_users
}

#Espace libre sur sda1
define service{
use generic-service
host_name machine-distante1
service_description /dev/sda1 Free Space
check_command check_nrpe!check_sda1
}

#Nombre total de processus
define service{
use generic-service
host_name machine-distante1
service_description Total Processes
check_command check_nrpe!check_total_procs
}

#Processus Zombie
define service{
use generic-service
host_name machine-distante1
service_description Zombie Processes
check_command check_nrpe!check_zombie_procs
}[/bash]

Voilà pour la configuration du base, on comprend vite les possibilités avec ça, de personnaliser la configuration selon nos propres souhaits :D Même si cette version de base est déjà très intéressante.

Pour prendre en compte les modifications, il suffit de redémarrer nagios :
[bash]/etc/rc.d/init.d/nagios restart[/bash]

La machine ajoutée doit être présente dans l’interface web de Nagios sur la page « Hosts ».

Vous pouvez maintenant ajouter autant de fichiers .cfg que voulu par machine dans le dossier « machines » de votre serveur nagios, et redémarrer nagios pour prendre en compte chaque nouvelle machine (en ayant installé et configuré NRPE sur la machine concernée) !

Vous êtes maintenant capable de démarrer l’utilisation de la solution nagios de manière efficace :D Bien sur lire les commentaires dans les fichiers de configuration exemple pour en savoir plus sur les possibilités, notamment les alertes etc. :D !

Liens et références utilisées pour la réalisation de cet article :

http://blog.lolo.org/?p=11
http://www.it-sudparis.eu/s2ia/user/procacci/Doc/nagios/nagios.html#htoc15
http://michauko.org/blog/2010/01/06/nrpe-monitorer-des-linux-avec-nagios/
http://michauko.org/blog/2009/10/07/mise-en-place-de-nagios/
http://www.nagios.org/download/addons
http://www.nagios.org/download/
Et une référence immanquables, avec des sujets toujours bien traités et lisibles (contrairement à moi j’avoue :p ) :
http://blog.nicolargo.com/nagios-tutoriels-et-documentations

Loading

Tags: , , , , ,

vendredi, mai 13th, 2011 GNU - Linux, Paranoïa, Reseau, Technologie Un commentaire

Configurer varnish-cache avec des virtualhosts, apache, fedora, redhat, centos

Cet article fait suite à celui ci : http://blog.inforeseau.com/2011/05/installer-varnish-depuis-sources-sur-fedora-11

Nous allons voir comment configurer varnish-cache afin d’optimiser notre serveur apache sur un seul serveur dédié (destiné à un public averti maitrisant la configuration d’apache).

Sur le post précédent nous avons compilé et installé varnish-cache, qui est donc dans un état fonctionnel, sur un port qui lui est propre. En suivant les différents documents cité en bas de ce poste comme sources, je vous propose ce petit mémo.

Comme toujours, il s’agit pour moi de garder une référence sur les travaux réalisés afin de prendre en main une technologie.

Dans cet article nous allons :
-Configurer varnish-cache avec des règles de base en VCL (varnish configuration language), pour prendre en charge nos virtualhost apache, et personnaliser les configurations selon le type de site.
-Configurer apache pour travailler avec varnish sur le même serveur, et pas forcément dans cet ordre :D

En ayant suivi mon POST précédent, votre installation de varnish-cache écoute actuellement le port 8080 (où le port que vous avez défini dans /etc/sysconfig/varnish pour la variable « VARNISH_LISTEN_PORT ». Apache écoute donc le port 80 (http), et varnish le 8080.
Pour que varnish-cache soit activé par défaut nous allons inverser ceci !
C’est varnish-cache qui va recevoir les demandes, et les gérer en fonction de règles que nous allons établir (le port que vous avez choisi doit être ouvert dans votre firewall évidemment).

On édite le fichier /etc/sysconfig/varnish et on change la variable « VARNISH_LISTER_PORT » en lui attribuant la valeur 80 (port http).
On édite le fichier /etc/varnish/default.vcl, et on va redéfinir le backend default en conséquence,votre fichier devra pour commencer contenir :
[bash]backend default {
.host = "127.0.0.1";
.port = "8080";
}[/bash]

Ceci défini que varnish-cache va par défaut demander le contenu au serveur local sur le port 8080, et tant qu’on ne redémarre pas le service, aucun soucis, les modifications n’ont pas d’impact.

On va maintenant éditer la configuration apache, afin de le faire écouter sur le port 8080.
Vous devez éditer le (ou les) fichier(s) de configuration apache qui définissent vos virtualhost (hôtes virtuels), ainsi que le port d’écoute par défaut. Généralement tout ceci est paramétré dans /etc/httpd/conf/httpd.conf.

Il faut donc remplacer le port par défaut sur l’ensemble des champs présents dans votre fichier de configuration comme suit :

FAITES UNE COPIE DE SAUVEGARDE AVANT DE MODIFIER POUR POUVOIR REVENIR EN ARRIERE AU BESOIN.

Listen 80 devient Listen 8080
NameVirtualHost *:80 devient NameVirtualHost *:8080
devient

Il faut ensuite formater les logs de apache pour que ça soit compatible avec varnish-cache, pour cela, il faudra ajouter la directive suivante (en plus de celles existantes, cherchez LogFormat dans votre configuration) :
[bash]LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" varnishcombined[/bash]

Puis, remplacer dans vos VirtualHost (hôtes virtuels), le format du log à utilisé :
CustomLog logs/xxxdomaine_access_log common devient CustomLog logs/xxxdomaine_access_log varnishcombined

A ce stade, nous sommes prêt à basculer sur le fonctionnement avec Varnish, mais avec les règles par défaut, ce qui peut conduire à des incompatibilités avec vos produits installés (wordpress, phpbb etc.). Si vous redémarrez tout de suite vos services (apache et varnish), chacun va utiliser le nouveau port et assurer le service, vous pouvez le faire, mais tant que vous n’aurez pas placé les règles, certains sites ne réagirons pas comme attendu (authentification impossible ou autre élément utilisant les cookies).

Pour adapter cela nous allons créer les règles qui vont bien en VCL, !

Je vais donner l’exemple avec quelques sites à moi, bien entendu vous adapterez à votre besoin.

L’idée pour moi et d’avoir une configuration par type de site (une pour wordpress, phpbb, sites autres etc.) et donc de conditionner la configuration selon le VirtualHost traité.

Voici donc les ajouts aux paramètres par défaut du fichier /etc/varnish/default.vcl :

[bash]backend default {
.host = "127.0.0.1";
.port = "8080";
}

#On va gérer les regles VCL selon les vhosts par hostname comme expliqué ici http://www.varnish-software.com/blog/virtual-hosts-varnish

#Traitement des requetes reçue depuis le net sur varnish-cache
sub vcl_recv {

if (! req.http.Host)
{
#soit j’affiche une erreur
#error 404 "Need a host header";
#Mais perso je prefere pouvoir appeler le serveur par son ip pour le site par défaut
#Alors je bypass et c’est le site par défaut sans cache qui sera affiché :
return (pass);

}
#On peut supprimer le www devant le host demandé si besoin, utile si on ne veut gérer que le site par défaut et unifier les logs.
#set req.http.Host = regsub(req.http.Host, "^www\.", "");
#Supprime l’eventuel :80 en fin de requete sur le host (permet de garantir que le filtre sera bien effectif.
set req.http.Host = regsub(req.http.Host, ":80$", "");

#Ici je pose une condition pour appeler le backend (serveur) et le fichier de configuration pour les sites donnés
#Pour les conditions, avec la tilde ~ je déclare que j’utilise les expression régulière regexp pour poser ma condition
if (req.http.Host ~ "blog.inforeseau.com|www.droledetroc.com")
{
#Permet de définir un backend (serveur) par site si besoin, comme chez moi tout est sur le meme serveur, ça sera identique partout !
set req.backend = default;
#appelle le fichier de règle RECV dédié à wordpress
include "/etc/varnish/wordpress_recv.vcl";
}
elsif (req.http.Host ~ "canada.maumautte.com|scrapblog.maumautte.com|www.kine-sport.com|just-cs.maumautte.com")
{
#Sinon (eslif) si ce sont les virtualhosts dans la condition ci dessus, je traite comme ceci :
set req.backend = default;
include "/etc/varnish/wordpress_recv.vcl";
#Oui c’est la meme configuration, mais j’aurai pu, par exemple renvoyer sur un autre serveur en backend, qui ne serait pas celui de cache (un autre serveur qui hebergerait le blog dont le backend peut être défini en haut du fichier)
}
elsif (req.http.Host ~ "forum.inforeseau.com|www.forum-scrapbooking.com")
{
#si c’est un forum à la base j’avais un bypass (pas de cache) car je n’avais pas les regles pour ignorer les cookies d’auth dans le cache, mais bande de veinards maintenant c’est fait, on verra le fichier plus bas.
set req.backend = default;
#return (pass);
#Application des règles dediées RECV à phpbb :
include "/etc/varnish/phpbb_recv.vcl";
}
else
{
#Par defaut, pour tous les autres sites "classiques", j’utilise le cache par défaut de varnish-cache
#Je défini quand même le serveur sur lequel le trafic est dirigé (oui toujours le même ici)
set req.backend = default;
return (lookup);
}
#ci dessous fin sub vcl_recv (fin du traitement des requêtes provenant du web)
}

##########################################################################
#On attaque la partie qui traite la lecture des pages sur le(s) serveur(s) source
sub vcl_fetch {
#Meme chose que pour le traitement amont, je ne redétaille pas, seul les fichiers associés sont différents.
if (req.http.Host ~ "blog.inforeseau.com|www.droledetroc.com")
{
include "/etc/varnish/wordpress_fetch.vcl";
}
elsif (req.http.Host ~ "canada.maumautte.com|scrapblog.maumautte.com|www.kine-sport.com")
{
include "/etc/varnish/wordpress_fetch.vcl";
}
#Attention, ne fonctionne pas avec le ou logique
#elsif (req.http.Host =="forum.inforeseau.com||www.forum-scrapbooking.com")
#On pass en regexp avec la tilde ~ comme indiqué plus haut
elsif (req.http.Host ~ "forum.inforeseau.com|www.forum-scrapbooking.com")
{
#si c’est un forum je bypass à la base, puis finalement non, j’ai tout corrigé comme plus haut.
#return (pass);
#J’ai mes propres règles (la loi c’est moi gnark gnark gnark) :
include "/etc/varnish/phpbb_fetch.vcl";
}
else
{
#Finalement on va delivrer le contenu caché (en cache hein, pas celui qui est sous la table!) pour augmenter les performances du reste des sites :
return (deliver);
}
#Fin vcl_fetch
}

########################################################################
#Puis tout ça c’est pour ajouter un peu de sécurité, masquer le fait que les pages sont traitées par varnish etc (bon avec ce post c’est sûr on se doute un peu que c’est le cas! niarf!)
sub vcl_deliver {
# Secure the header
remove resp.http.Via;
remove resp.http.X-Varnish;
remove resp.http.Server;
remove resp.http.X-Powered-By;
}[/bash]

Maintenant les 4 fichiers contenant les règles pour les sites qui sont en include (bah ouai, je ne suis pas un chien, je ne vous laisse pas en plan :) ) :

wordpress_recv.vcl (oui c’est de la récup de chez nicolargo, un grand merci à lui pour son super blog!) :
[bash] # Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;

# Post requests will not be cached
if (req.request == "POST") {
return (pass);
}

# Normalize encoding/compression
if (req.http.Accept-Encoding) {
if (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; }
}

# Remove has_js and Google Analytics __* cookies.
if (req.http.cookie) {
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(__[a-z]+|has_js)=[^;]*", "");
# Remove a ";" prefix, if present.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");
# Remove empty cookies.
if (req.http.Cookie ~ "^\s*$") {
unset req.http.Cookie;
}
}

# Serve the page
unset req.http.vary;
# If I am logged in to wordpress, I DO NOT WANT TO SEE cached pages
if ( req.url ~ "^/wp-(login|admin)" || req.http.Cookie ~ "wordpress_logged_in_" ) {
return (pass);
} else {
# If I’m just a regular visitor
# If the request is static
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)$") {
# Remove the cookie and make the request static
unset req.http.cookie;
return (lookup);
}
# Try to lookup in the cache
return (lookup);
}

# Cookie ? Not cacheable by default
if (req.http.Authorization || req.http.Cookie) {
return (pass);
}
[/bash]

wordpress_fetch.vcl :
[bash] if (req.request == "POST") {
return (pass);
}
# If the request is static
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)$") {
# Cache it, and make it last 2 hours
set beresp.ttl = 7200s;
# Make the request static by removing any cookies set by those static files
unset beresp.http.set-cookie;
# Deliver the cached object
return (deliver);
}
# If I am logged in to wordpress, I DO NOT WANT TO SEE cached pages
if (req.http.cookie ~ "wordpress_logged_in") {
return (pass);
} else {
# Cache anything for 2 minutes. When the cache expires it will be cached again and again, at the time of the request
set beresp.ttl = 120s;
return (deliver);
}
[/bash]

phpbb_recv.vcl :
[bash] # Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;

# Post requests will not be cached
if (req.request == "POST") {
return (pass);
}

# Normalize encoding/compression
if (req.http.Accept-Encoding) {
if (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; }
}

# Serve the page
unset req.http.vary;
# If I am logged in to phpbb, I DO NOT WANT TO SEE cached pages
if ( req.url ~ "^/(admin|adm)" || req.http.Cookie ~ "phpbb2hirikiki" || req.http.Cookie ~ "phpbb3_5xoui" ) {
return (pass);
} else {
# If I’m just a regular visitor
# If the request is static (sauf html/htm car on utilise url rewriting donc html=php)
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz)$") {
# Remove the cookie and make the request static
unset req.http.cookie;
return (lookup);
}
# Try to lookup in the cache
return (lookup);
}

# Cookie ? Not cacheable by default
if (req.http.Authorization || req.http.Cookie) {
return (pass);
}
[/bash]
Note : oui ça ressemble à celui de wordpress, notez juste les noms des cookies qui doivent correspondre aux noms de cookies que vous avez choisi dans votre config phpbb (on peut aussi identifier ça dans les préférences firefox, quand vous êtes sur votre site, en affichant les cookies dans l’onglet « vie privée »), et les pages html qui ne sont pas cachée car j’utilise de l’url-rewriting,et donc les pages html ne sont pas des pages statiques :D .

phpbb_fetch.vcl :
[bash]# Do not cache POST requests
if (req.request == "POST") {
return (pass);
}
# If the request is static (sauf html/htm utilisé en url_rewriting et donc dynamique)
if (req.url ~ "\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz)$") {
# Cache it, and make it last 2 hours
set beresp.ttl = 7200s;
# Make the request static by removing any cookies set by those static files
unset beresp.http.set-cookie;
# Deliver the cached object
return (deliver);
}
# If I am logged in to phpbb, I DO NOT WANT TO SEE cached pages
if (req.http.Cookie ~ "phpbb2ronours" || req.http.Cookie ~ "phpbb3_5xr75") {
return (pass);
} else {
# Cache anything for 2 minutes. When the cache expires it will be cached again and again, at the time of the request
set beresp.ttl = 120s;
return (deliver);
}
[/bash]

Voilà pour les fichiers contenant les règles pour chacun des sites.
Pour en apprendre plus en VCL vous trouverez plein d’exemples ici :
http://www.varnish-cache.org/trac/wiki/VCLExamples

Maintenant on est prêts à la mise à feu :
[bash]/etc/rc.d/init.d/httpd restart
/etc/rc.d/init.d/varnish restart[/bash]

Ayé, on est à fond ! :D, c’est maintenant Varnish qui gère les requêtes HTTP sur le port 80, puis qui, en fonction du site demandé, va réaliser les traitements adaptés.

Comme dirait Nicolargo, les commandes utiles :
varnishlog : affiche les log de varnish
varnishstat : affiche les stats depuis le dernier lancement de varnish et les tâches s’évanouissent! (arf désolé j’ai pas pu résister)
Explication sur les valeurs de varnishstat : http://kristianlyng.wordpress.com/2009/12/08/varnishstat-for-dummies/
varnishhist : Affiche un historique des requêtes faites sur votre machine.
varnishadm : pour administrer votre varnish en local.

Avec tout ça vous devriez pouvoir personnaliser la configuration à souhait, avec je l’espère une meilleure compréhension du système.

Ah oui j’oubliais! Varnish vous permet aussi de faire du load balancing / failover ! Vous pouvez en lire plus ici :
http://www.varnish-cache.org/trac/wiki/LoadBalancing
Bien sûr ça implique d’avoir plusieurs machines (au moins un frontal et 2 serveurs de contenu – backend)

Note : Si vous utilisiez des outils de statistiques en php, ceux-ci ne fonctionneront plus correctement car les pages distribuées par le cache ne sont donc plus traitées en php, c’est le but !

La doc en détail : http://www.varnish-cache.org/docs/2.1/

Sources :
http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html
http://www.varnish-cache.org/trac/wiki
http://www.varnish-cache.org/trac/wiki/VarnishAndWordpress
http://www.varnish-cache.org/docs/2.1/tutorial/vcl.html
http://blog.inforeseau.com/2011/05/installer-varnish-depuis-sources-sur-fedora-11
http://www.varnish-software.com/blog/virtual-hosts-varnish

Loading

Tags: , , , , , , , ,

vendredi, mai 6th, 2011 GNU - Linux, Innovation, Reseau, Technologie 9 Comments

Installer Varnish depuis les sources sur Fedora 11

Le post du jour va traiter de l’installation de varnish depuis les sources sur Fedora 11 de manière manuelle.

Varnish-cache est un serveur proxy qui va mettre en cache les pages demandées afin d’éviter au « moteur » de les recalculer systématiquement. Varnish-cache est un outil simple et puissant permettant un usage multiple, de la simple mise en cache à la répartition de charge comme on peut le lire ici : http://www.varnish-cache.org/docs/2.1/tutorial/advanced_backend_servers.html

Pour faire simple, vanish-cache reçoit les requêtes http sur un port que l’on défini dans son fichier de configuration, et rediriger la requête sur le (ou les) « backend » défini. On entend par « backend », le serveur qui fournit le contenu, typiquement apache, sur la même machine physique, ou encore sur un (ou plusieurs) autre(s) serveur(s).

Ce mode d’installation diffère légèrement de l’installation par paquets dans la mesure ou les fichiers de configuration ne sont pas positionnés au même endroit. (Généralement dans /usr/local/etc au lieu de /etc pour la config, et /usr/local/(bin|sbin) au lieu de /bin|/sbin).

On va donc dans notre dossier préféré pour compiler les programmes depuis la source, et on télécharge le programme en dernière version (2.1.5) au moment de ce post (Notez qu’il vaut mieux généralement passer par le dépot de votre distribution, ou une version packagée pour appliquer les mises à jour plus facilement), ici on vise l’aspect didactique, si vous maîtrisez le manuel, vous aurez gérer encore plus facilement les installations « packagées », car la seul différence se situe au niveau des chemins au final.

[bash]cd /usr/local/src
wget http://repo.varnish-cache.org/source/varnish-2.1.5.tar.gz
tar xvzf varnish-2.1.5.tar.gz[/bash]

On va commencer par installer les dépendances (voir ici http://www.varnish-cache.org/docs/2.1/installation/install.html#compiling-varnish-from-source):
[bash]yum install automake autoconf libtool ncurses-devel libxslt groff pcre-devel pkgconfig[/bash]

Varnish est maintenant décompressé, on va entrer dans le dossier de configurer, compiler, installer.

On va dans le dossier et on lance l’opération :
[bash]cd varnish-2.1.5
sh autogen.sh
sh configure
make[/bash]

Varnish est maintenant compilé et le binaire fonctionnel (en cas d’erreur, s’assurer que toutes les dépendances sont bien installées).

Comme indiqué dans la documentation vous pouvez maintenant effectuer un test du programme :
[bash](cd bin/varnishtest && ./varnishtest tests/*.vtc)[/bash]
La plupart des tests doivent renvoyer « passed ». Il se peut qu’une erreur ou deux se glisse, mais pas plus, et c’est sans gravité. Si la plupart des tests ne fonctionnent pas (failed) alors vous avez un problème et il faut revoir la procédure.

On peut maintenant installer :
[bash]make install[/bash]

On copie le fichier de configuration par défaut à la bonne place :
[bash]cp redhat/varnish.sysconfig /etc/sysconfig/varnish[/bash]

On va lier le dossier « etc/varnish » créé lors de l’installation avec le chemin par défaut :
[bash]ln -s /usr/local/etc/varnish /etc/varnish[/bash]

Il nous faut maintenant copier le script de démarrage de varnish à la bonne place, et corriger les chemins dans celui ci.
[bash]cp redhat/varnish.initrc /etc/rc.d/init.d/varnish[/bash]

Puis on édite ce fichier (/etc/rc.d/init.d/varnish) pour corriger les chemins vers les binaires comme suit :
/usr/sbin/varnishd devient /usr/local/sbin/varnishd

Voilà pour le script de lancement/arrêt de varnish, que l’on ajoute dans chkconfig (pour pouvoir le lancer automatiquement plus tard) :
[bash]chkconfig –add varnish[/bash]

Dans le fichier /etc/sysconfig/varnish on peut consulter les options par défaut qu’il faut adapter si vous le souhaitez. Dans mon cas, je souhaite positionner le cache dans un autre endroit, car je manque de place sur la racine.
Pour cela je vais donc changer la valeur de « VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin » pour le faire pointer vers un dossier de mon choix créé pour l’occasion. Libre à vous de faire cette modification selon votre configuration.

Il faudra aussi définir un utilisateur qui existe sur votre système (ou en créer un : adduser varnish), et adapter les « DAEMON_OPTS » à la ligne
[bash]-u varnish -g varnish[/bash]
avec l’utilisateur de votre choix.

Le dossier /usr/local/var/varnish devra appartenir à cet utilisateur et à son groupe (chown utilisateur:groupe /usr/local/var/varnish).

Il faut créer un mot de passe pour l’accès à l’interface d’administration :
[bash]echo "votre-password">/etc/varnish/secret[/bash]

On va maintenant créer une configuration de base pour tester la solution.
On ouvre le fichier /etc/varnish/default.vcl dont le contenu doit être totalement commenté par défaut, et on y ajoute ceci en bas du fichier :

[bash]backend default {
.host = "127.0.0.1";
.port = "80";
}[/bash]

Cette configuration va permettre de lancer un essai sans modifier la configuration de votre machine. On défini en gros que la source par défaut est votre serveur sur le port 80, soit le site affiché par défaut quand vous allez sur http://ip_serveur/.

On lance donc le processus :
[bash]/etc/rc.d/init.d/varnish start[/bash]

Vous pouvez maintenant consulter les statistiques et vérifier ainsi que ça tourne en tapant :
[bash]varnishstat[/bash]
(on quitte les stats en appuyant sur la touche « q »)

En fonction de la valeur que vous avez défini dans le fichier /etc/sysconfig/varnish pour la variable « VARNISH_LISTEN_PORT », vous pouvez consulter la page affichée par varnish à l’adresse :
http://votre_serveur:port (où port = la valeur choisie dans le fichier de configuration).

Si vous avez un firewall comme iptables, vous devrez ouvrir le port pour pouvoir consulter la page sur ce port.
Par exemple pour mon test sur le port 8080 :
[bash]iptables -A INPUT -p tcp –dport 8080 -j ACCEPT[/bash]
(ou éditer directement votre fichier /etc/sysconfig/iptables et relancer iptables pour prendre en compte la modif)

Si votre site s’affiche c’est gagné il est pris en compte par varnish sur ce port.

Note : Pour avoir des infos en cas de plantage, il faut lancer varnishd avec les options définies dans /etc/sysconfig/varnish et le parametre « -d », sans quoi varnish ne renvoie aucune information relative au plantage !

Enfin pour rendre le service varnish actif au démarrage nous activons le service avec chkconfig :
[bash]chkconfig –level 345 varnish on[/bash]

Pour la suite, comme la configuration avec par exemple wordpress je vous invite à lire cet excellent POST :
http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html
ainsi que le wiki de varnish :
http://www.varnish-cache.org/trac/wiki
OU BIEN, la suite de l’opération en configurant varnish-cache avec la gestion des virtualhost :
http://blog.inforeseau.com/2011/05/configurer-varnish-cache-avec-virtualhosts-fedora-redhat-centos

Sources utilisées pour ce post :
http://www.varnish-cache.org
http://www.varnish-cache.org/trac/wiki/VarnishAndWordpress
http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html

Loading

Tags: , , , , , ,

vendredi, mai 6th, 2011 GNU - Linux, Reseau, Technologie 2 Comments
Not f'd — you won't find me on Facebook
mai 2011
L M M J V S D
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
 

 
Suivez moi sur twitter - follow me on twitter
 
Follow on LinkedIn
[FSF Associate Member]
 
Free Software, Free Society
VIRTUALISATION :
Compacter une image virtualbox VDI
Bon petit tutoriel esxi
Marche d'appliances vmware
Installer ESXi sur un disque IDE
Installer ESXi 3.5 sur un disque USB
Installer proxmox avec DRBD et migration / réplication à chaud
Installer OSSEC avec VMware
Information sur le VDI
SECURITE - FIREWALL :
Ouvrir des ports dynamiquement iptables - knockd
Autre tres bon tuto knockd
Docs Arp poisoning - Anglais
Metasploit test de pénétration
Zone H - sites piratés en temps réel
Blog invisible things
Tips protection sécurité wordpress
Pfsense - distribution firewall opensource - adsl internet failover
Iproute 2 mini how to - linux advanced routing
ClearOS - la passerelle sécuritaire lan - wan
HAUTE DISPONIBILITE :
CDN - Accélération de la distribution de données
drbd iscsi ocfs2 dm multipath tutoriel
Load balancing LVS
Load balancing opensource list
HA-Proxy :
HAproxy - http load balancer
Simple tutoriel HAproxy
HAproxy - debian tutoriel
Centos - Ip failover
Configuratoin DM-Multipath Redhat
VMware Doubletake - continuité
Quelques liens sur la réplication MySQL : Manuel MySQL, chapitre sur la réplication
Manuel MySQL, Tutoriel clair sur la mise en place
Autre tuto sur la mise en place de la réplication MySQL
Références pour optimisation du serveur MySQL
Utilisation de EXPLAIN mysql pour optimiser vos bases
optimiser vos bases - requetes et index
STOCKAGE RESEAU :
Un outil de clonage disque en reseau
Internet NAS 250Go 250 accès VPN
Server ISCSI avec Ubuntu tuto
ISCSI centos redhat tutoriel
Gérer et étendre un LVM
Créer sa piratebox ! trop cool
Deaddrops, les clés USB dans les murs, aussi cool !
OPTIMISATION WORDPRESS :
Télécharger Xenu
Comment utiliser Xenu
optimisation hébergement wordpress
Super howto wordpress (En)
Test de charge serveur web - Load impact
VPN - ROUTEUR - LAN:
Zeroshell - le mini-routeur wifi tout en un
Retroshare, votre réseau d'échange crypté!
Openvpn sur centos redhat
Intégrer Linux dans active directory
Routage inter-vlan avec Linux
Routage avec OSPF
Network Weathermap
TENDANCES - WEB:
Boutons twitter
Analyser les tendances des recherches Google
Protocole sitemap - robots.txt
Creer des animations CSS3
Code php pour interagir avec twitter
E reputation
Jquery
TRUCS ET ASTUCES GNU/LINUX :
Tuxmachines.org - Actus et tips linux
Configurer GRUB2 et grub2 ici
Panoet - en anglais - tips & tricks
Readylines tips and trick pertinents
Squid Clamav - proxy antivirus
Apprendre Unix en 10 minutes
13 tips sur les expressions régulières
IE Sous linux IES
LDAP 2.4 Quickstart guide
Tutoriel LDAP
Installation annuaire LDAP
Serveur Mail Postfix - Dovecot - LDAP - MDS
Créer un linux personnalisé en ligne - custom linux
Super site sur linux - en
Capistrano - déploiement automatisé
MONITORING :
Nagios tutoriel et doc
Nagios plugin NRPE tuto
Nagios plugin NRPE autre tuto
Nagios plugin NRPE officiel
Zabbix - fonctionnalités
Zabbix - installation
Guide MRTGsys - grapher la charge locale
MRTGsys - ajouter des graphs
MRTGsys - interpréter les données
Shinken - Monitoring
Thruk Monitoring webinterface
Shinken - Tutoriel
Shinken - Référence chez Nicolargo
AUTRES LIENS :
RemixJobs IT jobs
USB Multiboot
Reset mot de passe windows
Java python et autres tips, intéressant !
Forum inforeseau
Open Clipart
Excellent comic en ligne
Inforeseau.fr