Catégories
Image Open-source Planet-libre Web

Gérer vos photos avec OpenPhoto, un service auto-hébergé

C’est suite à un tweet sur l’abandon du développement de la version GNU/Linux de Picassa par les équipes de Google que j’ai entendu parler pour la première fois du projet OpenPhoto (bien que comme nous allons le voir les deux sujets ne soient pas liés).

OpePhoto propose d’héberger dans un « cloud » vos photos, permettant ainsi un accès dématérialisé (plus besoin d’apporter sa clé USB pour montrer les photos de vacances à ses parents/amis).

OpenPhoto propose pour cela deux solutions:

  • un service en ligne proposant de gérer vos photos (importation, catégories, tag, applications smartphones, API…) mais en les hébergeant dans votre « cloud » (Dropbox ou votre espace de stockage Amazon S3 et prochainement Google Drive).
  • une version communautaire et libre permettant d’auto-héberger son propre serveur. Cette version propose en plus un stockage local des photos (sans passer par Dropbox ou Amazon S3).

C’est sur cette deuxième configuration que nous allons nous pencher dans ce billet en proposant une procédure d’installation et de configuration de Open Photo sur une machine Debian Squeeze avec NGinx , PHP-FPM et MySQL (la procédure doit être la même sous Ubuntu, mais je n’ai pas vérifié).

Note: à l’heure de la rédaction de ce billet, il y a peu ou très peu de documentation sur le Web sur comment installer OpenPhoto sur un serveur Nginx (alors que l’on trouve un tas de procédure pour les autres serveurs Web du marché sur le GitHub officiel…). Si une âme généreuse veut proposer une adaptation de ce billet dans le même formalisme que l’installation sous Apache, je pense que le projet serait très reconnaissant… (je m’en suis chargé).

Préparation de l’installation

Je pars sur le principe ou vous avez une machine Debian sur laquelle Nginx et PHP-FPM sont déjà installé. Si ce n’est pas le cas, vous pouvez suivre ce billet.

En plus, il faudra installer les paquets suivants:

sudo apt-get install mysql-server git-core php5-dev php5-mysql php5-curl curl php5-gd php5-mcrypt php5-imagick php-pear exiftran

On configure PHP en éditant les variable suivantes dans le fichier /etc/php5/fpm/php.ini (à adapter à votre besoin, notamment si vous avez un appareil photo avec un capteur générant des images > 16 Mo):

file_uploads = On
upload_max_filesize = 16M
post_max_size = 16M

On active également l’oAuth (pour l’authentification des applications tierces comme par exemple les applis iPhone et Android):

sudo pecl install oauth
sudo sh -c "echo \"extension=oauth.so\" >> /etc/php5/conf.d/oauth.ini"

On redémarre PHP-FPM pour prendre en compte les modifications:

sudo service php-fpm restart

Installation de OpenPhoto

On créé ensuite un répertoire dans notre serveur Web (/var/www/openphoto) et on télécharge la dernière version de la version communautaire (libre) de OpenPhoto:

sudo mkdir /var/www/openphoto
sudo git clone git://github.com/photo/frontend.git /var/www/openphoto

Puis on prépare l’arborescence:

sudo mkdir /var/www/openphoto/src/userdata
sudo mkdir /var/www/openphoto/src/html/photos
sudo mkdir /var/www/openphoto/src/html/assets/cache
sudo chown -R www-data:www-data /var/www/openphoto

Enfin on génère le fichier de configuration Nginx /etc/nginx/sites-enabled/openphoto pour le site OpenPhoto (à adapter également à votre configuration, notamment au niveau du server_name):

server {
	listen 80;
	server_name openphoto.mondomaine.com;
	root /var/www/openphoto/src/html; 

	index  index.php;
	client_max_body_size 25M;
	default_type text/html;
	charset utf-8;

	if (!-e $request_filename) {
		rewrite ^/([^?]*)(\?+([^?]*))*$ /index.php?__route__=/$1&$3 last;
	} 

	# PHP scripts -> PHP-FPM server listening on 127.0.0.1:9000
	# Check cache and use PHP as fallback.
	location ~* \.php$ {
                 try_files $uri =404;

                 fastcgi_pass 127.0.0.1:9000;
                 fastcgi_index index.php;
                 include fastcgi_params;
		 fastcgi_ignore_client_abort off;
                 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	}

	# Global restrictions configuration file.

	location = /favicon.ico {
		log_not_found off;
		access_log off;
	}

	location = /robots.txt {
		allow all;
		log_not_found off;
		access_log off;
	}

	location ~ /\. {
		deny all;
		access_log off;
		log_not_found off;
	}

	location ~ \.ini$ {
		deny all;
		access_log off;
		log_not_found off;
	}

	add_header Cache-Control "max-age=315360000";
	# Mise ne cache des ressources statiques
	location ~* ^.+\.(jpg|jpeg|gif|css|png|js|xml)$ {
		expires 30d;
		access_log off;
	}
}

On redémarre NGinx pour prendre en compte le site:

sudo service nginx restart

Puis on crée une nouvelle base de donnée MySql. Notez sur une feuille, le nom de la base (openphoto), le nom de l’utilisateur (openphoto) et le mot de passe associé (openphotomdp2012):

# mysql -u root -p
Enter password: 

mysql> create database openphoto;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON openphoto.* TO "openphoto"@"localhost" IDENTIFIED BY "openphotomdp2012";
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> exit
Bye

Configuration initiale de OpenPhoto

La suite de la configuration se fera à partir d’un navigateur Web, plus besoin de la ligne de commande :).

On doit dans un premier temps créer un compte sur le site OpenPhoto (même si on utilise pas la version en ligne et seulement une version auto-hébergé). Une fois le mail de confirmation reçu et la confirmation effectué, vous pouvez poursuivre l’installation en vous rendant à l’URL: http://openphoto.mondomaine.com (remplacer mondomaine.com par votre domaine que vous avez configurez dans le fichier de configuration NGinx). Si vous n’avez pas de domaine, il est possible de passer directement par l’adresse IP de votre machine.

Vous devez arriver sur la page suivante:

On entre:

  1. l’adresse email associé à votre compte OpenPhoto
  2. on laisse le thème par défaut et on clique sur « Continue to step 2 »

On passe à la deuxième étape de l’installation:

On sélectionne:

  1. une base de donnée de type MySQL (que l’on a préalablement créer dans le chapitre précédant)
  2. un stockage local des photos (on peut noter qu’il est possible de mixer stockage local et Dropbox)
  3. on passe à la troisième et dernière étape

Elle permet de configurer notre base de donnée MySQL (reprendre votre petite feuille…):

A la fin de cette procédure, votre serveur OpenPhoto est prêt !

Prise en main et premières impressions

La première chose à faire est d’importer quelques photos. On peut utiliser la page Upload qui propose une importation par Drag & Drop (ou sélection plus classique dans le gestionnaire de fichiers) ou bien l’application dédiée de votre SmarthPhone (Android et iPhone). Les images sont téléchargés sur votre serveur avec une très élégante barre de progression. On note au passage qu’OpenPhoto utilise les dernières technologies HTML5.

On peut ensuite éditer les images en y ajoutant une description, des tags, des coordonnées GPS, des droits (public ou privé) et une licence. Ces informations sont bien sûr récupérées automatiquement si elles sont présentes dans les méta-données du fichier.

Elle est pas belle ma fille ? 🙂

OpenPhoto permet de créer des groupes d’utilisateurs ayant des droits sur certaines photos. Par exemple, si vous créez un groupe Famille, alors il sera possible de classer vos photos familiales dans ce groupe afin qu’elles ne soient visibles que par vos proches. Pour grouper vos photos dans des groupes, le plus simple est d’aller dans le menu Manage, de sélectionner les photos en question (par un simple clic sur le bouton pin) puis de cliquer sur le bouton « Batch edit » et enfin de séléctionner le groupe.

Mes premières impressions sont très bonnes. OpenPhoto est rapide, stable. Le seul problème que j’ai rencontré est au niveau de l’affichage de la Gallery ou les photos sont déformées. Je vais essayer de le pousser un peu en important un grand nombre d’images (je ferai une màj du billet).

On sent une grande marge de manoeuvre au niveau des fonctionnalités proposées. Il est d’ailleurs possible de voter avec la communauté pour influencer la roadmap du logiciel sur les futures fonctions. J’aime le fait qu’OpenPhoto se concentre uniquement sur la gestion des images, contrairement à OwnCloud dont j’avais parlé dans un précédent billet.

Que pensez-vous de ce genre de service ?

Êtes vous prêts à franchir le pas et d’auto-héberger vos photos sur une de vos machines ?

Catégories
Open-source Planet-libre Systeme

Apprentissage de Qemu/LibVirt par l’exemple

La rédaction des billets de ce blog nécessite de travailler sur plusieurs systèmes d’exploitations différents. Plutôt que de monter une salle machine dans ma maison (pas sur que ma compagne soit d’accord), j’ai donc opté pour un virtualisation sur un serveur dédié OVH qui a le gros avantage de disposer d’une RAM conséquente de 16 Go (pour une machine en l’an 2012). Travaillant la plupart du temps du temps sous Linux, mon choix c’est donc porté sur la solution Qemu/KVM (Kernel-based Virtual Machine).

Installation de Qemu/KVM

Pour que Qemu/KVM ait des performances acceptables, il faut vérifier que votre processeur soit compatible avec les extensions de virtualisation. Sous Linux, il est facile de vérifier cela avec la ligne de commande suivante.

[cce lang= »bash »]

egrep ‘^flags.*(vmx|svm)’ /proc/cpuinfo >/dev/null && echo OK || echo KO

[/cce]

Sur mon serveur de test (Kimsufi 16G chez OVH) pas de problème de ce coté là. J’obtiens un beau OK.

Le serveur peut donc supporter la virtualisation hardware. Chez OVH, le noyau par défaut est statique, il n’est donc pas possible d’ajouter dynamiquement des modules (comme le kvm_intel par exemple). Il faut donc suivre cette procédure. La dernière version des noyaux semble intégrer par défaut les modules KVM.

On peut ensuite passer à l’installation des briques logicielles (environ 257 Mo à télécharger):

  • qemu-kvm – Full virtualization on x86 hardware
  • virtinst – Programs to create and clone virtual machines
  • libvirt-bin – the programs for the libvirt library

On utilise les versions disponibles dans les dépôts Debian:

[cc lang= »bash »]

sudo apt-get install qemu-kvm virtinst libvirt-bin

[/cc]

Un petit reboot de la machine pour être sûr que tous les modules sont chargés avant de poursuivre.

Création de sa première machine virtuelle (VM)

Nous allons commencer par créer une machine virtuelle avec comme système hôte une Ubuntu Desktop 11.10. Une machine virtuelle a besoin d’un conteneur dans lequel elle va pourvoir s’exécuter: ce conteneur s’appelle une image disque. Ensuite, il faudra installer le système hôte à l’intérieur de cette image disque.

Il est possible d’utiliser la ligne de commande pour effectuer ces opérations (ce qui ouvre la voie à une automatisation par scripts). Nous aborderons cela un peu plus loin dans l’article. Pour commencer, nous allons utiliser le module libvirt-manager qui propose une interface graphique (GTK) permettant d’administrer à distance (via un tunnel SSH) son serveur d’hypervision Qemu/KVM.

On commence par vérifier que le daemon d’administration est bien lancé sur le serveur d’hypervision (ce qui devrait être le cas si vous avez suivi les étapes d’installations de ce billet):

[cc lang= »bash »]

sudo /etc/init.d/libvirt-bin status

Checking status of libvirt management daemon: libvirtd running.

[/cc]

Ensuite il faut ajouter votre utilisateur (nicolargo dans mon cas) dans les groupes ‘libvirt‘ et ‘kvm‘:

[cc lang= »bash »]

sudo usermod -a -G libvirt nicolargo

sudo usermod -a -G kvm nicolargo

[/cc]

Sur la machine GNU/Linux cliente (disposant d’une interface graphique), il faut installer les packages (par exemple sous Debian/Ubuntu):

[cc lang= »bash »]

sudo apt-get install virt-manager

[/cc]

Au lancement du client, il faut cliquer sur le menu File > Add connection…

Puis paramétrer la connexion vers votre serveur:

Notre serveur est alors disponible dans la liste, on peut alors configurer ses propriétés:

On configure le type de réseau que l’on va utiliser. Comme je ne dispose que d’une seule adresse publique sur mon serveur OVH Kimsufi, j’utilise la translation d’adresse (voir l’explication dans un chapitre suivant) qui est configurée par défaut:

Puis on configure les répertoires ou l’on pourra trouver les ISOs pour l’installation des machines hôtes:

 

 

Et voila le résultat après téléchargement de quelques images ISO depuis le répertoire ~/iso (le serveur disposant d’une accès 100 Mbs direct sur Internet, cela va assez vite !).

On peut passer à la création de la VM proprement dite en cliquant sur le bouton « Create a new virtual machine ». On accède alors à un wizard:

On entre le nom de la VM (sans espace):

Puis l’image ISO qui va nous servir pour l’installation du système d’exploitation (le « Browse » sur le serveur peut prendre un certain temps):

On défini ensuite les ressources de la VM (CPU et mémoire). A noter que la limite à 2 Go de RAM sur ma configuration de test:

On donne ensuite la taille de l’image disque qui contiendra notre VM. Je conseille 16 Go pour les OS récents.

Enfin on finalise la configuration coté réseau (NAT) et hyperviseur (KVM):

Une fenêtre avec un déport d’affichage devrait alors s’afficher et l’installation du système guest (Ubuntu 11.10) commencer:

 Il ne vous reste plus qu’à finaliser l’installation !

Utilisation de sa VM

Une fois l’installation de la VM effectuée (voir le chapitre précédant). Celle-ci devrait apparaître dans la liste proposé par Virtual Machine Manager. Pour la lancer, il faut sélectionner la VM puis cliquer sur le bouton ‘play’ (Power On the virtual machine):

Et voilà le travail:

Niveau performance ?

Il ne faut pas s’attendre à des miracles. La virtualisation par Qem/KVM bien qu’aillant fait de gros progrès dans les dernières versions restent en dessous d’une solution comme VmWare ou Xen. Elles sont par contre suffisante dans mon cas ou je souhaite valider des procédures et des logiciels système et réseau.

Gestion en ligne de commande

Création de l’image disque

On commence par créer un répertoire ~/vm qui va contenir toutes mes images disques:

[cc lang= »bash »]

mkdir ~/vm

[/cc]

Puis on utilise la commande qemu-img pour générer l’image disque « vierge »:

[cc lang= »bash »]

cd ~/vm

qemu-img create -f qcow2 debian6server.qcow2 16G

[/cc]

Cette dernière commande va donc générer une image disque nommée debian6server.qcow2 de type qcow2 (voir ci-dessous la liste des types disponibles sous Debian 6) avec une taille maximale de 16 Giga octets.

Sur mon système, la liste des « types » d’image disque est la suivante:

  • raw: pas de compression, l’image disque est directement « dumpée » dans un fichier
  • host_device
  • qcow2: format par défaut de Qemu (Qemu Image Format)
  • qcow: ancien format utilisé par Qemu (ne pas utiliser pour la création de nouvelle image disque)
  • vdi: format compatible avec VirtualBox
  • vmdk: format compatible avec VMWare
  • vpc: format compatible avec VirtualPC

Il est possible de convertir une image d’un format à un autre. Par exemple, si vous avez une image au format VMWare et que vous voulez la convertir vers un format Qcow2, il suffit de saisir la commande suivante:

[cc lang= »bash »]

qemu-img convert -f vmdk disk.vmdk -O qcow2 disk.qcow2

[/cc]

Création de la VM

Pour installer la VM, nous avons besoin de l’image ISO du système d’exploitation à installer (Debian 6 server dans mon exemple). On va donc télécharger cette image sur notre serveur (c’est dans ces moments là que l’on est heureux d’avoir un serveur avec une connexion à 100Mbps vers Internet…):

[cc lang= »bash »]

mkdir ~/iso

cd ~/iso

wget http://cdimage.debian.org/debian-cd/6.0.3/i386/iso-cd/debian-6.0.3-i386-CD-1.iso

[/cc]

Maintenant que nous disposons de l’image disque ~/vm/debian6server.qcow2 et du média d’installation ~/iso/debian-6.0.3-i386-CD-1.iso, nous allons créer la machine virtuelle en utilisant la couche d’abstraction libvirt.

Pourquoi utiliser libvirt plutôt que d’utiliser directement les commandes équivalentes Qemu ? Si demain vous décidez de changer votre système de virtualisation, vos procédures/scripts resteront les mêmes. En effet libvirt communique de manière transparente vers un grand nombre de systèmes de virtualisation en proposant en bonus une API de développement (notamment en Python).

On utilise donc la commande suivante pour créer la VM:

[cc lang= »bash »]

virt-install –ram=2047 –name=debian6server –file=/home/nicolargo/vm/debian6server.qcow2 –cdrom=/home/nicolargo/iso/debian-6.0.3-i386-CD-1.iso –hvm –vnc –noautoconsole

[/cc]

Note: la commande virt_install ne semble pas trop aimer les ~ dans les paths. Il faut donc donner le chemin absolu.

Note2: La taille maximale de RAM que je peux allouer est de 2047Mo.

Cette commande va donc créer une VM nommée debian6server qui disposera de 2 Go de RAM (d’ou l’avantage de faire tourner votre hyperviseur sur une machine disposant de pas mal de RAM / 16 Go dans mon cas sur une Kimsufi 16G).

Si tout est ok, le message suivant devrait s’afficher:

Domain installation still in progress.

You can reconnect to the console to complete the installation process.

Pour l’accès à la console (déport VNC via un tunnel SSH), je vous conseille d’utiliser l’interface d’administration de libvirt que vous pouvez lancer sur un PC client disposant d’une interface graphique.

Gestion du réseau par translation

Mon serveur dispose d’une seule adresse IP publique. Les VM auront donc des adresses IP privées et l’on utilisera la translation s’adresse (NAT) pour permettre au VM de sortir sur Internet (voir ce billet pour la création d’un réseau par NAT).

Certaines configurations sont à faire sur votre serveur:

[cc]

sudo sh -c « echo 1 > /proc/sys/net/ipv4/ip_forward »

[/cc]

[cc]

sudo vi /etc/sysctl.conf

# Uncomment the next line to enable packet forwarding for IPv4

net.ipv4.ip_forward=1

[/cc]

Si vous utilisez des règles Iptables alors il faut ajouter les lignes suivantes dans votre scripts (attention de bien vérifier que votre script ne repositionne pas la valeur net.ipv4.ip_forward à 0… je me suis fais avoir):

[cc]

# Qemu rules (NAT VM and allow VM to DHCP)

/sbin/iptables -t nat -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE

/sbin/iptables -A INPUT -i virbr0 -j ACCEPT

/sbin/iptables -A OUTPUT -o virbr0 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p udp -m udp –dport 53 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p tcp -m tcp –dport 53 -j ACCEPT

/sbin/iptables -A INPUT -i virbr0 -p udp –dport 67:68 –sport 67:68 -j ACCEPT

/sbin/iptables -A FORWARD -d 192.168.122.0/24 -o virbr0 -m state –state RELATED,ESTABLISHED -j ACCEPT

/sbin/iptables -A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT

/sbin/iptables -A FORWARD -i virbr0 -o virbr0 -j ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward

[/cc]

Petite note pour les guests « BSD »

Pour un guest sous OpenBSD, il faut penser à effectuer les actions suivantes pour faire fonctionner correctement la carte réseau:

  • arrêter la VM
  • éditer le fichier /etc/libvirt/qemu/OpenBSD_5.0.xml

[cce]

<interface type=’network’>

<model type=’e1000′>

</interface>

[/cce]

  • Relancer la VM

Sources utilisées lors de la rédaction de cet article:

Catégories
Open-source Planet-libre Reseau Systeme

Installation et configuration de Munin, le maître des graphes

Munin est un logiciel de supervision permettant de centraliser la gestion des graphes de données RRDTools. Il permet en quelques commandes que nous allons détailler dans ce billet de générer des graphes complexes pour surveiller vous machines et les processus qui tournent dessus.

Voici un exemple de graphe sur les statistiques remontées par un serveur utilisant Varnish:

Introduction

Munin est proposé sous la forme de deux packages complémentaires: munin et munin-node.

Le premier (munin) est à installer sur votre serveur de supervision (appelé maître). Son objectif principal est de récupérer les données venant des machines à surveiller puis de générer des graphes qui seront présentés aux utilisateurs via une interface Web.

Le second  (munin-node) est à installer sur toutes les machines à superviser (appelées noeuds). Son objectif est de collecter les informations systèmes en utilisant des plugins (présent dans le package munin-node et dans munin-plugins-extra).

La communication entre le serveur maître et les machines noeuds utilise, par défaut le protocole TCP/4949 (initialisation de la connexion TCP de la part du serveur maître).

Installation de Munin

Pour la suite de ce billet (et sauf mention spécifique), je partirai sur le principe ou vous utilisez des machines sous Debian/Ubuntu.

Installation de Munin sur le serveur maître

Le serveur maître doit disposer d’un serveur Web (voir ce billet pour installer simplement NGinx sur votre système) configuré avec le répertoire root par défaut: /var/www.

Comme Munin est présent dans les dépôts officiels, il suffit de saisir la commande suivant qui va installer le package maître ainsi que le package esclave histoire de pouvoir superviser son serveur de supervision…:

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

sudo ln -s /var/cache/munin/www /var/www/munin

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

En faisant pointer un navigateur Web vers l’URL:

http://votreserveurdesupervision/munin

Vous devriez voir s’afficher les statistiques de votre serveur. Il faut attendre quelques minutes avant de voir les premiers graphes, le temps que les bases de données soient renseignées.

Installation de Munin sur les machines noeuds

Installation des noeuds sous GNU/Linux

Là encore c’est assez simple:

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

La configuration de Muni sur les machines noeuds est centralisée dans le fichier /etc/munin/munin-node.conf. Il faut éditer ce fichier pour y configurer l’adresse IP de votre serveur maître à la ligne suivante:

# A list of addresses that are allowed to connect. This must be a

# regular expression, since Net::Server does not understand CIDR-style

# network notation unless the perl module Net::CIDR is installed. You

# may repeat the allow line as many times as you'd like

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

Cette configuration (à adapter à votre besoin) va autoriser la machine maître d’adresse IP 192.168.1.200 à se connecter sur cette machine noeud pour y récupérer les données à superviser.

Il faut ensuite relancer le service Munin-node pour faire prendre en compte la nouvelle configuration:

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

Installation des noeuds sous Windows

Le projet Munin ne fourni pas de « node » pour WIndows, il faut donc se retourner du coté de la communauté pour trouver notre bonheur. En l’occurrence du coté du logiciel Munin-Node-Win32 disponible au téléchargement sur cette page.  Il suffit de lancer l’installer pour que l’installation et le lancement du processus en tache de fond soit effectué (procédure testé sous Windows 7).

Installation des noeuds sous MacOS

Si vous avez à surveiller des machines sous Mac OS X, il va falloir mettre un peu plus les mains dans le cambouis. En effet, il faut obligatoire passer par l’installation des gestionnaires de paquets Fink ou MacPorts. Je vous conseille la lecture du Wiki officiel.

Configuration des plugins sur les machines noeuds

Nous allons voir dans cette sections comment configurer ce que l’on souhaite superviser sur les machines noeuds. Munin utilise le fichier  /etc/munin/plugin-conf.d/munin-node (ainsi que tous les fichiers se trouvant dans le même répertoire) pour configurer les paramètres des plugins (bien souvent de simples script Perl).

Le répertoire /etc/munin/plugins/ contient la liste des plugins utilisables par la machine noeud et le répertoire /usr/share/munin/plugins/ l’ensemble des plugins. En y regardant de plus prêt, le répertoire  /etc/munin/plugins/ fait des liens symboliques vers le répertoire /usr/share/munin/plugins/.

Pour voir la liste des plugins disponibles sur le noeud, on peut utiliser:

# sudo munin-node-configure

Exemple de l’ajout des plugins NGinx (permettant de surveiller un serveur Web NGinx) sur un noeud:

Pour faire prendre en compte un nouveau plugin sur un noeud (node) il faut faire un lien symbolique entre le fichier en question dans ce répertoire et /etc/munin/plugins/. Par exemple pour accéder aux stats de mon serveur NGinx:

sudo ln -s /usr/share/munin/plugins/nginx_status /etc/munin/plugins/nginx_status

sudo ln -s /usr/share/munin/plugins/nginx_request /etc/munin/plugins/nginx_request

Il est quelquefois necessaire d’installer des dependances pour que le plugin fonctionne.

Pour voir les dépendances nécessaire il suffit de saisir la commande:

sudo munin-node-configure --suggest | grep nginx

nginx_request | yes | no [LWP::UserAgent not found]

nginx_status | yes | no [LWP::UserAgent not found]

Il faut donc installer la librairie perl contenant le module LWP qui est présente dans le package libwww-perl sur Debian/Ubuntu:

sudo apt-get install libwww-perl

Cela a l’air OK:

sudo munin-node-configure --suggest

nginx_request | yes | yes

nginx_status | yes | yes

On peut faire prendre en compte la configuration par Munin-node:

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

Configuration du maître pour prendre en compte les machines noeuds

Une fois toutes vos machines noeuds configurés (voir le chapitre précédant), il faut maintenant modifier la configuration du serveur maître pour les prendre en compte. Là encore, fidèle à la philosophie Unix, la configuration est centralisé dans le fichier /etc/munin/munin.conf.

En plus des répertoires systèmes en début de fichier:

# The next three variables specifies where the location of the RRD

# databases, the HTML output, logs and the lock/pid files. They all

# must be writable by the user running munin-cron. They are all

# defaulted to the values you see here.

#

dbdir /var/lib/munin

htmldir /var/cache/munin/www/

logdir /var/log/munin

rundir /var/run/munin

Il faut configurer la liste des noeuds de la manière suivante:

# A simple host tree for mondomaine.com

[maitre.mondomaine.com]

address 127.0.0.1

[noeud1.mondomaine.com]

address noeud1.mondomaine.com

[noeud2.mondomaine.com]

address noeud2.mondomaine

Reste à relancer le serveur Munin pour prendre en compte la configuration:

su - munin --shell=/bin/bash

/usr/share/munin/munin-update

exit

En faisant pointer un navigateur Web vers l’URL:

http://votreserveurdesupervision/munin

Puis par exemple les graphes sur l’occupation mémoire:

Pour voir une démonstration en ligne des capacités de Munin, vous pouvez consulter ce serveur maître qui est en accès libre.

Plus de plugins ?

Un des gros avantage de Munin est le fait de pouvoir simplement écrire de nouveaux plugins en utilisant votre langage favori (nous reviendrons bientôt sur ce sujet dans un prochain billet).  Pas mal d’exemples sont proposés  dans le dépôt GitHub suivant (vous devriez trouver votre bonheur).
Catégories
Reseau

Configurer un tunnel IPSec Cisco entre deux réseaux locaux

Un petit poste « pense-bête » pour configurer un tunnel IPSec avec « pre-share key » (c’est à dire une clés secrète seulement connue par les deux sites) et cryptage AES 256 bits entre deux LAN connectés à Internet par des routeurs Cisco (compatible avec IPSec…).

Configuration du routeur A

crypto isakmp policy 1
 authentication pre-share
 lifetime 86400

crypto isakmp key AZERTYUIOPQSDFGHJKLMWXCVBNAZERTY address 80.80.80.2

crypto ipsec transform-set MATS esp-aes 256 esp-sha-hmac

crypto map MAMAP 10 ipsec-isakmp
 set peer 80.80.80.2
 set transform-set  MATS
 match address IPSEC-TUN

ip access-list extended IPSEC-TUN
 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

interface FastEthernet 0/1
 crypto map MAMAP

Configuration du routeur B

crypto isakmp policy 1
 authentication pre-share
 lifetime 86400

crypto isakmp key AZERTYUIOPQSDFGHJKLMWXCVBNAZERTY address 80.80.80.1

crypto ipsec transform-set MATS esp-aes 256 esp-sha-hmac

crypto map MAMAP 10 ipsec-isakmp
 set peer 80.80.80.1
 set transform-set  MATS
 match address IPSEC-TUN

ip access-list extended IPSEC-TUN
 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

interface FastEthernet 0/1
 crypto map MAMAP
Catégories
Open-source Systeme

Configuration de la pile IP Ubuntu en ligne de commande

Un petit mémo à usage général pour tout ceux qui, comme moi, ont besoin de configurer à distance via SSH (c’est à dire en ligne de commande) la pile IP d’une distribution Ubuntu (la procédure doit normalement être la même sous Debian).

Configuration de l’adresse IP, masque et passerelle

On commence par configurer le ou les interfaces réseau via le fichier /etc/network/interfaces.

La structure est simple, voici un exemple:

# Configuration de l’adresse de loopback

auto lo

iface lo inet loopback

# Interface coté Internet (en DHCP)

auto eth0

iface eth0 inet dhcp

# Interface coté LAN (statique)

auto eth1

iface eth1 inet static

address 192.168.1.1

netmask 255.255.255.0

gateway 192.168.1.254

Configuration des serveurs DNS

Si vous n’utilisez pas la configuration de vos serveurs DNS par DHCP, vous pouvez passer par le fichier /etc/resolv.conf. Ce dernier permet de configurer le nom du domaine et l’adresse des serveurs DNS.

search monbeaudomaine.com

nameserver 192.168.1.1

nameserver 208.67.219.99

On applique la configuration du réseau

/etc/init.d/networking restart

Voili, fin du pense bête…

Catégories
Open-source Reseau

Structure des fichiers de configuration de Nagios 3

smalllogo7.gif

Le passage en version 3.0 de Nagios (l’outil de monitoring système et réseau) a apporté son lot de nouveautés. L’une d’elle est la réorganisation des fichiers de configuration. Nous allons dans ce billet détailler cette structure et préparer notre configuration de Nagios pour qu’elle soit facile à administrer…

Catégories
Open-source Reseau Systeme

Un pont FreeBSD

25/02/2010: mise à jour du tutoriel pour FreeBSD 8.0

Voici un petit tutorial pour configurer un routeur FreeBSD (machine avec deux interfaces réseaux minimum, par exemple pour protéger votre réseau) en mode pont (ou bridge dans la langue de Beckham).

Avant de commencer un petit rappel sur ce qu’est un pont réseau: le « livre de main » qui va bien.

La configuration est la suivante:

  • un PC avec deux interfaces réseaux (minimum) nommées bge0 et bge1
  • un OS de type FreeBSD (6.2 8.0 dans notre cas)
  • de l’huile de coude

Ce que l’on veut obtenir:

  • un pont réseau entre ces deux interfaces
  • une adresse IP privée assignée aux interfaces (192.168.1.254/24)

Configuration du pont

On veut donc créer un pont entre les interfaces bge0 et bge1.

La première chose à faire est de demander le chargement du module au boot:

[shell]
# vi /boot/loader.conf
bridge_load="YES"
if_bridge_load="YES"
[/shell]

Et configurer les interface réseau, notamment la nouvelle interface virtuelle que nous allons nommer bridge0:

[shell]
# vi /etc.rc.conf
ifconfig_bge0="up"
ifconfig_bge1="up"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm bge0 addm bge1 up"
ifconfig_bridge0_alias="inet 192.168.1.254/24"
[/shell]

Et voila le travail !

Catégories
Open-source Reseau

Exemple de configuration de Nagios

Ce post fait suite à celui sur l’installation de Nagios sur une machine Linux. Nous allons y décrire les fichiers de configurations nécessaires pour surveiller (« to monitor ») un réseau simple comporant: une machine client, une machine serveur avec un serveur Web et une serveur FTP et une liaison Internet.

Note: les fichiers de configurations données en exemple dans ce post se basent sur la version 2.8 de Nagios.

Sous Fedora Linux, les fichiers de configurations de Nagios se trouvent dans le répertoire /etc/nagios/ (/usr/local/etc/nagios sous BSD). Le fichier nagios.cfg définie l’ensemble des sous fichiers de configurations grâce aux variables cfg_file:


#cfg_file=/etc/nagios/localhost.cfg
cfg_file=/usr/local/etc/nagios/timeperiods.cfg
cfg_file=/usr/local/etc/nagios/contacts.cfg
cfg_file=/usr/local/etc/nagios/contactgroups.cfg
cfg_file=/usr/local/etc/nagios/hosts.cfg
cfg_file=/usr/local/etc/nagios/services.cfg
cfg_file=/usr/local/etc/nagios/hostgroups.cfg

Il faut également configurer le fichier cgi.cfg (en partant de cgi.cfg-sample):

authorized_for_system_information=admin
authorized_for_configuration_information=admin
authorized_for_system_commands=admin
authorized_for_all_services=admin
authorized_for_all_hosts=admin
authorized_for_all_service_commands=admin
authorized_for_all_host_commands=admin

Définition des plages horaires

La première étape consiste à définir les périodes de temps que nous allons pouvoir utiliser dans les autres fichiers de configurations. Pour simplifier, nous allons juste créer la période 24×7 (tout les jours, toutes les heures…). Pour cela, il faut éditer le fichier /usr/local/etc/nagios/timeperiods.cfg:

# Time periods definitions
##########################
# 7d/7 24h/24
define timeperiod {
timeperiod_name 24×7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}

Définition des contacts

Nous allons ensuite définir les contacts. C’est à dire les personnes devant être prevenu par un moyen ou un autre (mail, SMS…) quand une alerte est générée par Nagios (par exemple quand votre serveur Web ne répond plus).

Il faut pour cela modifier deux fichiers, /usr/local/etc/nagios/contacts.cfg pour la définition du/des contacts:

# Contacts defintions
#####################
define contact {
contact_name nico
alias Nicolas
host_notification_period 24×7
service_notification_period 24×7
host_notification_options d,u,r
service_notification_options w,u,c,r
host_notification_commands host-notify-by-email
service_notification_commands notify-by-email
email nico@votreadressemail.com
}

Nous venons donc de créer un contact nommé « nico » qui sera joingnable 24 heures sur 24, 7 jours sur 7 par mail.

Le deuxième fichier (/usr/local/etc/nagios/contactgroups.cfg) permet d’intégrer le nouvel utilisateur dans un groupe:

# Contacts groups definition
############################
define contactgroup {
contactgroup_name admins
alias Administrators
members nico
}

Nous avons donc ajouté « nico » dans le groupe « admins ».

Définition des machines à surveiller

Entrons dans le vif du sujet en déclarant les machines que l’on veut surveiller. Cette définition sefait dans le fichier /usr/local/etc/nagios/hosts.cfg:

On commence le fichier en définissant un template:

# Nagios server – Hosts definitions
###################################
# Templates
#———-
define host{
name template-host
check_command check-host-alive
max_check_attempts 2
check_interval 5
active_checks_enabled 1
passive_checks_enabled 0
check_period 24×7
notification_interval 60
notification_period 24×7
obsess_over_host 0
check_freshness 0
event_handler_enabled 0
flap_detection_enabled 0
process_perf_data 0
retain_status_information 1
retain_nonstatus_information 1
contact_groups admins
register 0
}

Puis on ajoute la définition pour notre routeur d’accès à Internet (Freebox, 9box, OrangeBox, Trucbox…):

# Ma box
#————
define host{
use template-hosts
host_name monrouteuramoi
alias Mon routeur à moi c’est une Freebox
address 192.168.100.254
}

celle de mon PC client:

# Mon PC client
#————
define host{
use template-hosts
host_name monpcamoi
alias Mon MacBook Pro à moi
address 192.168.100.2
}

et enfin celle de mon serveur:

# Mon serveur
#————
define host{
use template-hosts
host_name monserveuramoi
alias Mon serveur Linux à moi
address 192.168.100.1
}

on termine en surveillant la liaison Internet (pour cela on va pinguer un serveur Web):

# Mon liaison Internet
#————
define host{
use template-hosts
host_name maliaisonamoi
alias Ma liaison ADSL à moi
address www.free.fr
parents monrouteuramoi
}

Vous pouvez remarquer dans cette dernière définition que nous avons définie « monrouteuramoi » comme père de ma « maliaisonamoi ». Ainsi, si le routeur n’est plus accéssible, Nagios n’essayera plus de surveiller la liaison Internet.

Définition des services à surveiller

Une fois les machines définies, nous devons décider ce que nous allons surveiller dessus. Cette configuration se fait grâce au fichier /usr/local/etc/nagios/services.cfg.

Nous allons commencer par un template:

# Templates
#———-
define service{
name template-services
active_checks_enabled 1
passive_checks_enabled 0
parallelize_check 1
obsess_over_service 1
check_freshness 0
notifications_enabled 0
event_handler_enabled 0
flap_detection_enabled 0
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
check_period 24×7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups admins
notification_interval 240
notification_period 24×7
notification_options c,r
register 0
}

Puis par la surveillance du routeur:

# monrouteuramoi
#———
define service {
host_name monrouteuramoi
use template-services
service_description Ping
check_command check-host-alive
}

De mon PC client:

# monpcamoi
#———
define service {
host_name monpcamoi
use template-services
service_description Ping
check_command check-host-alive
}

mon serveur (on surveille également le serveur HTTP et le serveur FTP):

# monserveuramoi
#———
define service {
host_name monserveuramoi
use template-services
service_description Ping
check_command check-server-alive
}
define service {
host_name monserveuramoi
use template-services
service_description Web serveur
check_command check_http
}
define service {
host_name monserveuramoi
use template-services
service_description FTP serveur
check_command check_ftp
}

et enfin la liaison Internet:

# maliaisonamoi
#———
define service {
host_name maliaisonamoi
use template-services
service_description Ping
check_command check-server-alive
}

Définition des groupes de machines

La dernière étape consiste à définir un groupe de machine dans le fichier /usr/local/etc/nagios/hostgroups.cfg:

# Mon réseau à moi
define hostgroup{
hostgroup_name monreseauamoi
alias Mon reseau
members monrouteuramoi, monpcamoi, monserveuramoi, maliaisonamoi
}

et voila la configuration touche à sa fin, il ne reste plus qu’a vérifier la syntaxe de vos fichiers de configuration avec la commande suivante:

# nagios -v <nagios.cfg>

Si tout est ok, vous pouvez relancer le serveur Nagios:

# service nagios reload

That’s all folk !

Pour une description précise des options des fichiers de configuration de Nagios, c’est par ici.

Pour consulter l’ensemble des posts sur Nagios, c’est par là.