Tag - adminsys

Entries feed

Wednesday, December 10 2014

Modifier le registre de Windows depuis Linux

Vous connaissiez peut-être chntpw pour modifier le mot de passe d'un utilisateur Windows depuis un LiveCD linux ?

Et bien, bonne nouvelle, chntpw est encore plus puissant que cela : il permet de modifier aussi le registre de Windows depuis un LiveCD (par exemple System Rescue CD qui inclut cet utilitaire par défaut) :

  • on commence bien sûr par monter le disque sur lequel se trouve Windows
  • puis on commence à lire dans la Regedit : chntpw -l /path/to/windows/Windows/system32/config/software
  • pour se rendre dans HKey_Local_Machine/SYSTEM/MountedDevices, on va taper cd HKLMSYSTEMMountedDevices
  • la commande ls va permettre de lister les clés présentes
  • ed key va permettre de modifier ensuite une clé

Bien sûr, prudence dans toute action, il ne faut pas se tromper ! Sauvegardes nécessaires avant d'effectuer des opérations de la sorte. Dans mon cas, cela m'a permis de détruire une association de disque hasardeuse avec le contenu du disque C: automatiquement attribué à la lettre E: ce qui empêchait tout démarrage de Windows (qui n'aime pas démarrer sur E: s'il a été installé sur C: ... il doit y avoir des liens absolus laissés par l'installation !)

Sunday, November 23 2014

Température suivie avec un Raspberry Pi B+, une sonde DS18B20 et Munin

La sonde DS18B20 est une sonde de température 1-wire très facile d'utilisation avec le Raspberry Pi. Il y a de très nombreux sites et blogs qui en rapportent l'utilisation : par exemple http://www.framboise314.fr/mesure-de-temperature-1-wire-ds18b20-avec-le-raspberry-pi/ ou https://learn.adafruit.com/downloads/pdf/adafruits-raspberry-pi-lesson-11-ds18b20-temperature-sensing.pdf.

Je vais toutefois reprendre ici les principales étapes et me concentrer ensuite sur le suivi et l'affichage de la température via Munin.

Matériel

  • Un Raspberry Pi B ou B+ avec des GPIO libres
  • Une sonde DS18B20 (composant avec 3 pattes)
  • Une résistance 4.7 KOhms (des valeurs proches peuvent convenir également)
  • Quelques câbles

Montage électrique

Les sondes 1-wire peuvent être alimentées de 2 manières : en alimentant une des pattes à 3.3V ou bien en laissant le composant charger un condensateur avec les parasites ambiants et utilisant la charge de ce condensateur pour effectuer une messure. La 2e méthode a l'avantage de nécessiter un câble de moins dans l'installation mais il est possible qu'il faille être un peu plus patient pour effectuer des lectures de température (quelques secondes pour charger le condensateur selon le niveau des parasites).

Dans la suite, nous alimenterons directement le composant en 3.3V.

Nous allons donc simplement connecter :

  • la masse du capteur à un pin de masse
  • l'alimentation du capteur au pin 3.3V du Raspberry Pi
  • la patte centrale (lecture) au GPIO 4

et nous allons ajouter la résistance de 4.7KOhms en parallèle avec la sonde i.e. entre l'alimentation 3.3V et la ligne de lecture.

raspberry-pi-ds18b20-connections.jpg (image empruntée sur http://www.reuk.co.uk/DS18B20-Temperature-Sensor-with-Raspberry-Pi.htm)

Attention à ne pas inverser la masse et l'alimentation - cela pourrait endommager le composant. On peut se référer à cette documentation pour être certain de ne pas se tromper : http://datasheets.maximintegrated.com/en/ds/DS18B20.pdf. La masse se trouve sur la patte de gauche quand on regarde la face plate du composant avec les pattes vers le bas.

Paramétrons le Pi

On peut alors brancher le Pi, se connecter en SSH et charger les modules nécessaires à la lecture des GPIO :

modprobe w1-gpio
modprobe w1-therm

Il faut aussi modifier le fichier /boot/config.txt et ajouter cette ligne :

dtoverlay=w1-gpio

Pour ne pas avoir à les charger à nouveau à chaque re-démarrage du Pi, on ajoutera les 2 lignes suivants au fichier /etc/modules :

w1-gpio
w1-therm

Remarque : si vous prévoyez plus de 10 sondes, il est possible qu'il faille ajouter un fichier wire.conf dans /etc/modprobe.d avec ce contenu :

options wire max_slave_count=50

Si tout fonctionne, on doit alors voir un dossier au nom de la sonde apparaître dans le dossier /sys/bus/w1/devices :

cd /sys/bus/w1/devices
ls
>> 28-000005330085 w1_bus_master1

'' 28-000005330085'' est le nom de la sonde installée. Si nous avions plusieurs sondes sur le bus, nous verrions un dossier avec un nom unique pour chaque sonde. Si on entre dans le dossier, on accède aux différentes valeurs retournées par la sonde : le fichier w1_slave contient la température sur la 2e ligne en millièmes de degré Celsius :

4c 01 4b 46 7f ff 04 10 f5 : crc=f5 YES
4c 01 4b 46 7f ff 04 10 f5 t=20750

La petite ligne bash suivante (en remplaçant bien sûr le nom de ma sonde par celui de la vôtre !) extrait alors la température en °C :

cat /sys/bus/w1/devices/28-000005330085/w1_slave | grep "t=" | awk -F "t=" '{print $2/1000}'
>> 20.75

Relevons la température avec Munin

J'ai déjà évoqué Munin ici. Munin est un logiciel utilisé par le adminsys pour suivre les variables vitales de serveurs. Mais l'outil peut tout à fait être utilisé aussi pour suivre n'importe quelle variable accessible sur un ordinateur, par exemple la valeur de la température relevée par notre sonde !



Je ne détaillerai pas ici le paramétrage du serveur Munin (qui récolte régulièrement les données des clients, génère les graphes et les rend disponibles au travers d'un serveur http) mais seulement du client Munin.

On installe un client (noeud dans le vocabulaire de Munin) sur le Pi avec cette commande :

aptitude install munin-node

Le noeud/client munin fonctionne en récoltant les variables de scripts stockés dans /etc/munin/plugins : par défaut les plugins seront en fait des liens relatifs vers les scripts par défaut disponibles dans /usr/share/munin/plugins/. Si vous ne souhaitez suivre aucune variable vitale du Pi, vous pouvez supprimer tous les liens dans /etc/munin/plugins (si vous changez d'avis il suffira de les reprendre depuis /usr/share/munin/plugins).

Nous allons donc créer un nouveau script Munin pour collecter la température. Les scripts Munin sont tout simples - ils comprennent 2 parties : une partie qui décrit le graphique (et les éventuelles options graphiques que l'on souhaite voir appliquées) et une seconde partie imprime chaque variable et sa valeur sur chaque ligne. Par exemple, le script "memory" de Munin retourne les valeurs suivantes :

slab.value 8949760
swap_cache.value 0
page_tables.value 638976
vmalloc_used.value 954368
apps.value 21979136
free.value 291938304
buffers.value 35708928
cached.value 99397632
swap.value 0
committed.value 51347456
mapped.value 6803456
active.value 64913408
inactive.value 85291008

Nous allons donc générer un script qui imprime la valeur de notre sonde de la même façon dans /etc/munin/plugins :

nano temperature_1

et voici le contenu du script :

#!/bin/sh

case $1 in
   config)
        cat <<'EOM'
graph_title Temperature probe 1
graph_vlabel temperature_1
temperature_1.label temperature_1
EOM
        exit 0;;
esac

printf "temperature_1.value "
cat /sys/bus/w1/devices/28-000005330085/w1_slave | grep "t=" | awk -F "t=" '{print $2/1000}'

Si on exécute ce script (./temperature_1) voici la sortie :

temperature.value 21.5

On peut alors redémarrer le client Munin.

Lors de la prochaine collecte des données, le serveur Munin viendra récupérer la sortie du script temperature_1 et proposera alors les graphes standards de Munin pour cette valeur.

Si l'on dispose de plusieurs sondes, on peut alternativement multiplier les scripts (un script par sonde) ou alors demander au script d'imprimer les valeurs de chacune des sondes : les différentes valeurs seront alors affichées sur un même graphe !

ambient_temperature-day.png

Bon suivi de température !

Monday, November 10 2014

Obtenir une bonne note chez SSLLabs avec Pound

J'utilise Pound dans mon infrastructure, notamment pour sa capacité d'assurer tout le chiffrement en SSL/TLS entre mes serveurs et les clients.

Cependant, la version stable de Pound dans Debian Wheezy n'est pas patchée pour écarter les récentes "attaques" sur SSL/TLS à commencer par la corruption de SSLv3 (faille baptisée Poodle).

Si la version 2.7, la prochaine stable, disposera de tous les derniers raffinements, seule une branche non officielle pourra satisfaire le plus scrupuleux adminsys. Cette branche non officielle est maintenue par Joe Gooch (qu'il soit permis ici de le remercier !) et est disponible ici : https://github.com/goochjj/pound/tree/pcidss/v2.6.

Voici comment Joe décrit cette branche :

The other is called pcidss/v2.6, which is Pound 2.6, plus cipher and protocol patches necessary (initially) to pass PCI compliance, and as part of that is the directive to disable SSL3.

Compiler Pound 2.6-pcidss

  • Télécharger la dernière version ici : https://github.com/goochjj/pound/archive/pcidss/v2.6.zip
  • Dé-zipper l'archive et se rendre dans le dossier
  • Réaliser ensuite la compilation (le système devra bien sûr comporter tout le nécessaire à cela : gcc, build-essentials, libssl-dev...) :
./configure
make
make install
  • dans Debian, il semble que pound 2.6-pcidss s'installe dans /usr/local/sbin/pound alors que le paquet original l'installe dans /usr/sbin/pound. On peut donc remplacer l'ancienne version par la nouvelle et vérifier que l'utilitaire par défaut correspond bien à la nouvelle version :
pound -V

qui doit retourner 2.6-pcidss.

  • on peut alors modifier la configuration de Pound avec ces paramètres :
	DisableSSLv2
	DisableSSLv3

	Ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:-RC4:EECDH+aRSA+RC4:EECDH+RC4:EDH+aRSA+RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:RC4+SHA"
    	SSLHonorCipherOrder 1
	SSLAllowClientRenegotiation     0
  • et redémarrer Pound

Normalement, vous devriez désormais disposer d'un chiffrement SSL de qualité susceptible de vous faire obtenir un A (yes!) sur https://www.ssllabs.com/ssltest/ (si votre certificat est de bonne qualité - SSLLabs disqualifie tout de suite tout certificat auto-signé !).

StartSSL pour des certificats SSL "wildcard" à petit prix

Disposant de plusieurs domaines pour mes activités personnelles et professionnelles, j'utilisais jusqu'ici des certificats auto-signés pour sécuriser mes connexions avec SSL/TLS. Cependant, habituer l'utilisateur à "ajouter une exception de sécurité" sans réfléchir me déplaisait au plus haut point. J'ai donc finalement, poussé aussi par mon beau-frère, mis en place de jolis certificats validés par StartCom Ltd. (StartSSL).

Les tarifs pratiqués par StartCom Ltd./StartSSL sont beaucoup plus doux que ceux pratiqués par d'autres acteurs du domaine. Chez eux, on paye en effet le processus de validation d'identité mais ensuite l'émission des certificats est gratuite. Voilà qui est tout à fait intéressant et économique pour couvrir plusieurs domaines !

Ouvrir un compte chez StartSSL

La première étape consiste à se connecter sur http://startssl.com et à choisir "Sign-up" pour ouvrir un nouveau compte. On saisit ses informations personnelles (il faut qu'elles soient exactes si l'on prévoit de faire valider son identité !) puis le site installe automatiquement dans le navigateur un certificat/clé qui autorise ce seul navigateur à se connecter au site. Une bonne pratique consistera à sauvegarder de manière sûre ce certificat pour conserver l'accès au site StartSSL !

Profiter des certificats de niveau 1

Sans rien payer, il est alors possible de faire valider un domaine via le 'Validations Wizard' (la validation d'un domaine consiste à recevoir un courriel envoyé par exemple à postmaster@le-domaine-en-question.fr et à saisir le code de validation reçu) puis de créer des certificats de niveau 1.

Les certificats de niveau 1 sont une bonne base pour débuter mais il n'est notamment pas possible avec ce niveau de disposer de certificats "wildcard" (i.e. pour tous les sous-domaines d'un domaine). Pour bénéficier de cette fonctionnalité, il faut disposer d'un niveau 2.

Obtenir le niveau 2

Pour passer niveau 2, il faut d'une part :

  • soumettre des documents pour prouver son identité (photocopies de 2 pièces d'identité, éventuellement justificatif de domicile, éventuellement recevoir un appel de StartSSL sur son numéro de téléphone)
  • s'acquitter de la somme de 59,90$ (environ 48 euros)

Tout le processus s'effectue en ligne via le 'Validations Wizard', catégorie 'Personal identity validation'. Les gens de StartCom StartSSL sont extrêmement réactifs.

Dans mon cas, après quelques heures et quelques échanges par courriel et téléphone, mon identité a été vérifiée et mon niveau 2 validé.

Créer un certificat 'wildcard'

Une fois niveau 2, voici la marche à suivre :

  • sur le serveur que l'on souhaite protéger, nous allons générer une clé privée et un Certificate Sining Request (CSR) par la commande
openssl req -nodes -newkey rsa:4096 -sha256 -keyout cle-privee.key -out serveur.csr

Il est à noter que ce processus génère une clé privée sans mot de passe. Il est tout à fait possible de générer une clé avec mot de passe mais il faudra alors préciser le mot de passe correspondant aux logiciels serveurs qui utiliseront la clé pour crypter les échanges.

Au cours du processus, OpenSSL va demander quelques informations d'identité. Il est important de préciser dans le champ 'Common Name' le nom d'hôte à protéger : en l'occurrence *.le-domaine-en-question.fr si l'on souhaite bénéficier d'un certificat 'wildcard' pour le-domaine-en-question.fr.

Country Name (2 letter code) [AU]: FR
State or Province Name (full name) [Some-State]: Ile-de-France
Locality Name (eg, city) []: Mary-sur-Marne
Organization Name (eg, company) [Internet Widgits Pty Ltd]: MaSociété
Organizational Unit Name (eg, section) []: 
Common Name (eg, YOUR name) []: *.le-domaine-en-question.fr
Email Address []: postmaster@le-domaine-en-question.fr
A challenge password []: 
An optional company name []:
  • on peut alors afficher le contenu du CSR par
cat serveur.csr

et le conserver précieusement

  • de retour sur le site de StartSSL, se rendre dans le 'Certificates wizard'
  • choisir 'Webserver SSL/TLS certificate'
  • passer (bouton SKIP) l'étape de génération d'une clé privée puisque nous avons créé nous-même notre clé privée sur le serveur
  • copier alors le contenu du CSR dans le champ texte
  • sélectionner le domaine à protéger : seuls les domaines déjà validés peuvent être utilisés. On pourra par exemple saisir *.le-domaine-en-question.fr.
  • et voilà le certificat qui apparaît à l'écran. Il convient de copier ce certificat précieusement, par exemple dans un fichier wildcard.le-domaine-en-question.fr.crt.

Utiliser son tout nouveau certificat

Cette étape dépend ensuite du serveur utilisé (Apache, Pound, Nginx, ...). La plupart du temps, on regroupera le certificat obtenu de la part de l'autorité de certification et la clé privée dans un même fichier .pem. On pourra également inclure les certificats intermédiaires de l'autorité : https://www.startssl.com/certs/ca.pem et https://www.startssl.com/certs/sub.class2.server.ca.pem.

cat wildcard.le-domaine-en-question.fr.crt cle-privee.key ca.pem sub.class2.server.ca.pem > wildcard.le-domaine-en-question.pem

On pourra alors utiliser ce .pem sur son serveur, en s'assurant toutefois de bien le garder secret, car il contient notre clé privée !

Bon courage pour votre génération de certificats !

Friday, September 26 2014

Contrôleur RAID Dell PERC H310 (PowerEdge R220) et Linux, tout fonctionne !

La nouvelle gamme de serveur Dell PowerEdge R220 est équipée du contrôleur PERC H310.

Outre être compatible sans problème avec Debian Wheezy, ce contrôleur a le bon goût de pouvoir être suivi ("monitoré" si vous me pardonnez l'anglicisme) depuis Linux. En effet, comme tout le monde le sait, il est indispensable de suivre l'état d'un RAID tout au long de sa vie pour intervenir au plus vite en cas de panne de l'un des disques pour effectuer son remplacement.

Vérifier que vous avez bien un PERC H310

Le rendu de la commande

lspci

doit contenir cette ligne :

01:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] ![1000:0073] (rev 03)

Charger le module du kernel Linux adéquat

Cette carte est gérée par le module

megaraid_sas

que l'on peut charger, si nécessaire, avec la commande

modprobe megaraid_sas

Installer les utilitaires adaptés

Les paquets adaptés sont disponibles sur hwraid.le-vert.net. On peut les installer en ajoutant cette ligne dans /etc/apt/sources.list :

deb http://hwraid.le-vert.net/debian wheezy main

puis

aptitude update
aptitude install megactl megaraid-status

Il est désormais possible de surveiller l'état du RAID avec la commande :

megasasctl

ou

megasasctl -B

(si, comme le PERC H310, votre carte ne comporte pas de batterie donc vous ne voulez pas avoir d'alerte pour batterie manquante)

Aussi, en installant megaraid-status, un démon de surveillance du RAID a été installé. Il enverra un courriel à root lors tout défaut sur le RAID. Je vous invite à tester cette fonctionnalité en détériorant manuellement (en débranchant un disque de la grappe par exemple - en environnement de test hein !) le RAID. Voici le style de message reçu :

This is a RAID status update from megaraidsas-statusd.  The megaraidsas-status
program reports that one of the RAIDs changed state:

-- Arrays informations --
-- ID | Type | Size | Status
a0d0 | RAID 1 | 465GiB | DEGRADED

-- Disks informations
-- ID | Model | Status | Warnings
a0e*s0 | ATA TOSHIBA DT01ACA0 465GiB | rebuild
a0e*s1 | ATA TOSHIBA DT01ACA0 465GiB | online

There is at least one disk/array in a NOT OPTIMAL state.

Report from /etc/init.d/megaraidsas-statusd on cefepime

Recevoir les courriels système envoyés à root

Si vous ne voulez pas d'un serveur courriel compliqué sur votre serveur, vous pouvez déployer le rapide et simple nullmailer. Il se chargera de renvoyer vers l'adresse spécifiée dans /etc/nullmailer/adminaddr tout message envoyé à root.

Bonne surveillance de RAID sur PERC H310 !

Sunday, March 23 2014

L'importance du paramètre TimeOut dans Pound

Pound est un reverse-proxy et un load-balancer libre fort perfomant. Il faut toutefois savoir que par défaut Pound n'attend pas plus de 15 secondes la réponse du serveur sous-jacent avant de retourner une erreur : "An internal server error occurred. Please try again later". Un 'timeout' de 15 secondes est suffisant pour de nombreux cas - cependant certaines requêtes sont parfois plus longues par exemple quand il s'agit de déclencher des requêtes importantes sur des bases de données, de lancer le téléchargement d'une grosse archive dans ownCloud ou de toute autre opération susceptible de prendre plus de 15 secondes à un serveur (notamment quand celui-ci est fortement sollicité par ailleurs).

Il est dès lors possible d'augmenter la durée du 'TimeOut' en ajoutant cette ligne :

  • soit dans la configuration globale de pound
  • soit dans la définitiond d'un 'backend' spécifique
TimeOut 150

Si 150 secondes n'est pas adapté, on modifie bien sûr la valeur.

Voilà qui devrait faire disparaître la plupart des erreurs "An internal server error occurred. Please try again later" !

Monday, March 10 2014

Logrotate et OpenVPN

Logrotate est un outil fort pratique pour l'administrateur qui souhaite nettoyer automatiquement et périodiquement son dossier /var/log (on en parlait déjà ici et ici).

D'autre part, OpenVPN est un couple client/serveur performant pour la mise en place de réseaux privés virtuels. L'administrateur attentionné aimera que le serveur OpenVPN tienne à jour un flux de logs détaillés... mais avec de nombreux utilisateurs du VPN, les logs peuvent alors rapidement atteindre une taille très importante ! Logrorate est bien sûr la solution.

J'ai cependant eu quelques difficultés à trouver des options qui permettent à OpenVPN et Logrotate de fonctionner en bonne harmonie - je vous présente donc ci-dessous les paramétrages fonctionnels chez moi pour vous épargner (en tout cas je le souhaite) mes longs tâtonnements.

Dans la configuration d'OpenVPN, on a :

user openvpn
group openvpn
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log

Comme on peut le voir ci-dessus, je regroupe mes logs dans un même dossier et les logs sont écrits avec les droits d'exécution du serveur OpenVPN, à savoir l'utilisateur openvpn. log-append précise le fichier dans lequel les logs doivent être déposés.

Pour logrotate, dans /etc/logrotate/openvpn.conf, on a :

/var/log/openvpn/openvpn.log
{
    weekly
    rotate 52
    missingok
    notifempty
    delaycompress
    compress
    copytruncate
    postrotate
        /etc/init.d/openvpn restart
    endscript
}

J'espère que ces paramétrages permettront aussi chez vous l'harmonie entre OpenVPN et Logrotate !

Sunday, November 10 2013

Installation et paramétrage d'un serveur avec conteneurs LXC chez Online.net/Dedibox

Nous allons décrire ici l'installation et la paramétrage d'un serveur dédié chez Online.net (offres Dedibox). La description de l'installation ne sera peut-être pas exhaustive et se concentrera sur les points clés, ceux qui par exemple ont été bloquants lors de notre déploiement.

Au niveau des technologies utilisées...

Nous allons déployer une version Debian stable (7.x à l'écriture de ces lignes) avec LVM2 (pour le découpage de l'espace disque) étant entendu que le RAID est géré matériellement et ne demande pas de paramétrage au niveau du système. La technologie LXC (LinuX Containers) sera utilisée pour séparer les servicse dans plusieurs conteneurs indépendants.

Pour le réseau, chaque conteneur disposera de sa propre IPv6 et sera donc accessible directement. En IPv4 en revanche, on déploiera un réseau local IPv4 avec un NAT pour répartir le trafic sur les différents conteneurs.

Paramétrage du réseau IPv6 chez Online.net

Chez Online.net, un bloc /48 est attribué avec chaque serveur dédié. Pour gérer l'IPv6 sur le serveur, il faudra installer le client Dibbler (un client DHCPv6) :

aptitude install dibbler-client

puis modifier la clé DUID dans le fichier /var/lib/dibbler/client-duid pour insérer celle attribuée par Online.net dans l'interface d'administration du système. Enfin, on modifiera le fichier de configuration /etc/dibbler/client.conf tel que suit :

log-level 7
iface br0 {
    pd
    option dns-server
    option domain
}

On modifie alors le fichier /etc/network/interfaces pour contenir les éléments suivants :

auto br0
iface br0 inet static
    address 88.123.123.123
    netmask 255.255.255.0
    gateway 88.123.123.1
    bridge_ports eth0

iface br0 inet6 static
    address 2001:abcd:abcd:abcd::
    gateway fe80::123:1234:1234:1234
    netmask 56

Vous aurez bien sûr pris le soin de remplacer 2001:abcd:abcd:abcd:: par l'adresse IPv6 correspondant au bloc /56 que vous avez décidé d'attribuer à votre serveur dédié et de spécifier la bonne passerelle (la passerelle par défaut est aussi l'adresse du routeur auquel est connecté votre Dedibox, vous pourrez trouver dans les logs de Dibbler l'adresse de ce routeur). Et remplacer 88.123.123.123 par l'adresse IPv4 qui vous a été attribuée (et spécifier la passerelle correspondante).

Ce paramétrage correspond à la mise en place d'un pont réseau (bridge) ce qui permettra à toutes les machines virtuelles de communiquer entre elles et de partager les communications réseau.

On redémarre alors le réseau :

/etc/init.d/networking restart

(si vous êtes connecté en SSH, il faudra peut-être se reconnecter en utiliser les nouvelles adresses spécifiées - pour forcer la connexion SSH en IPv6 il faudra utiliser ssh -6 et ssh -4 pour forcer l'IPv4)

puis on redémarre Dibbler par les commandes habituelles :

/etc/init.d/dibbler-client stop 
/etc/init.d/dibbler-client start

Une fois les conteneurs en place, nous reviendrons sur ce paramétrage pour y apporter quelques légères modifications.

Création de volumes virtuels avec LVM pour héberger les conteneurs

Chaque conteneur sera contenu dans un espace logique géré par LVM. Cela permettra notamment une manipulation aisée pour le redimensionnements, les sauvegardes...

Lors de l'installation initiale, nous avons donc pris le soin de garder une grosse partition /dev/sdaX non utilisée - c'est elle que nous allons déclarer comme volume physique pour LVM.

Il faut d'abord s'assurer que /dev/sdaX n'est pas mentionné dans /etc/fstab et le cas échéant commenter la ligne correspondante.

Puis on crée le volume physique :

pvcreate /dev/sdaX
vgcreate vg /dev/sdaX

et 2 volumes logiques de 50 Go :

lvcreate -n Nom1 -L 50g vg
lvcreate -n Nom2 -L 50g vg
mkfs.ext4 /dev/vf/Nom1
mkfs.ext4 /dev/vf/Nom2

Installation de LXC et déploiement du premier conteneur

aptitude install lxc lxc lxctl bridge-utils debootstrap unzip

installera les éléments nécessaires. Puis on modifiera /etc/fstab pour contenir :

cgroup        /sys/fs/cgroup        cgroup        defaults    0    0

La commande lxc-checkconfig permet de vérifier si tout est paré et donné des aides pour la résolution d'éventuels problèmes. Une fois que tous les paramètres de lxc-checkconfig sont au vert, on se lance pour de vrai !

A noter que le template Debian 7 inclus par défaut pour LXC dans Debian 7 est défectueux (cf. 'The Debian 7 template is broken' in [https://wiki.debian.org/LXC |https://wiki.debian.org/LXC] et la solution proposée ici par Rob van der Hoeven). Les lignes ci-dessous correspondent à la solution proposée par Rob.

On déploie un template fonctionnel :

cd /usr/share/lxc/templates/
wget http://freedomboxblog.nl/wp-content/uploads/lxc-debian-wheezy.gz
gzip -d lxc-debian-wheezy.gz
chmod u+x lxc-debian-wheezy

et on lance la création du premier conteneur :

lxc-create -n myfirstcontainer -t debian-wheezy

On déplace alors le conteneur dans le premier disque logique LVM que nous avions créé précédement :

cd /var/lib/lxc/
mv myfirstcontainer myfirstcontainer-tmp
mkdir myfirstcontainer
mount /dev/vg/Nom1 myfirstcontainer
cd myfirstcontainer-tmp
cp -R * ../myfirstcontainer/
cd ..
rm -Rf myfirstcontainer-tmp

et on paramètre le conteneur comme suit dans /var/lib/lxc/myfirstcontainer/config :

lxc.utsname = container1
lxc.network.type = veth
lxc.network.veth.pair = vethcontainer1
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = 192.168.0.101/24  #on attribue une adresse IPv4 de réseau local
lxc.network.ipv4.gateway = 192.168.0.1  #la passerelle, nous allons attribuer cette adresse ensuite à l'hôte physique
lxc.network.hwaddr = 00:11:D0:14:84:BE  #attention, à modifer par une valeur aléatoire si vous installez plusieurs machines pour qu'il n'y ait pas collision !
lxc.network.ipv6 = 2001:abcd:abcd:abcd::101/56  #une adresse appartenant au bloc /56 attribué au serveur dédié

et on modifie les paramétrages réseau au sein du conteneur dans /var/lib/lxc/myfirstcontainer/rootfs/etc/network/interfaces :

auto eth0
iface eth0 inet static
    address 192.168.0.101

iface eth0 inet6 static
    address 2001:abcd:abcd:abcd::101
    netmask 56
    post-up ip -6 route add default via 2001:abcd:abcd:abcd::

Sur la machine hôte, on modifie alors les paramètres tel que suit :

  • on indique à Dibbler de ne pas chercher à paramétrer l'interface virtuelle vethcontainer1 en ajoutant dans la configuration de Dibbler :
iface vethcontainer1 no-config
  • on met en place le réseau IPv4 par :
ip addr add 192.168.0.1 dev br0
ip route add 192.168.0.0/16 dev br0
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
  • on met en place le réseau IPv6 par :
ip -6 route add 2001:abcd:abcd:abcd::101 dev br0
  • on modifie les paramétrages réseau du système en modifiant /etc/sysctl.conf :
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.accept_ra = 2

et sysctl -p pour prendre en compte ces paramétrages.

Si la connectivité IPv6 disparaît, alors il faudra se reconnecter en IPv4 et lancer les commandes suivantes :

ip -6 route add aa:bb:cc:dd:ee::/64 dev br0
ip -6 route add default via aa:bb:cc:dd:ee::1 dev br0
/etc/init.d/dibbler-client stop
/etc/init.d/dibbler-client start

en remplaçant aa:bb:cc:dd:ee::1 par l'adresse de la passerelle IPv6 (cette adresse est normalement communiquée par les Router Advertisements).

Tout semble alors prêt pour le démarrage du conteneur !

Lancement du conteneur

lxc-start -d -n myfirstcontainer

et on peut alors s'y connecter en console via :

lxc-console -n myfirstcontainer

Par défaut, le mot de passe root est root (c'est le paramétrage par défaut du template que nous avons utilisé - il va de soi que nous allons rapidement modifier ce paramétrage).

Pour quitter la console LXC, il faudra faire Ctrl+a puis d.

Dans le conteneur, on pourra vérifier que :

  • ping 192.168.0.1 fonctionne (ping de la machine hôte physique)
  • ping 8.8.8.8 fonctionne (ping vers l'extérieur, le web)
  • ping -6 2001:abcd:abcd:abcd:: fonctionne (ping de la machine hôte physique en IPv6)
  • ping -6 2001:4860:4860::8888 fonctionne (ping vers le web en IPv6)

Si tout fonctionne comme attendu, on peut alors poursuivre l'installation du système. On pourra par exemple :

  • créer des conteneurs additionnels (en adaptant quelque peu le paramétrage réseau afférent)
  • paramétrer iptables et ip6tables sur l'hôte physique et les conteneurs pour protéger les systèmes et rediriger le trafic IPv4 sur les conteneurs
  • installer Pound comme reverse proxy pour diriger le trafic HTTP/HTTPS IPv4 vers les différents conteneurs sous-jacents

Exemple de configuration iptables sur l'hôte physique

#!/bin/bash
IPTABLES='/sbin/iptables';

CT1_HOST="192.168.0.101";
CT2_HOST="192.168.0.102";
MONITORING_ONLINE="88.190.254.18";
LAN="192.168.0.0/24";
WAN_IFACE="br0";
WAN_IP="88.123.123.123";
# Flushing tables
$IPTABLES -F
$IPTABLES -X
$IPTABLES -t nat -F
# Define default policy
$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT

$IPTABLES -A INPUT -j ACCEPT -d $LAN;
$IPTABLES -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED

# Temporary - SSH access open to all IPs on port 22 but Fail2ban is working.$
$IPTABLES -A INPUT -j ACCEPT -p tcp --dport 22
# Opens to ping from online monitoring
$IPTABLES -A INPUT -j ACCEPT -p icmp -s $MONITORING_ONLINE

# Accepts connection to ports 80 and 443
$IPTABLES -A INPUT -j ACCEPT -p tcp --dport 80
$IPTABLES -A INPUT -j ACCEPT -p tcp --dport 443

# Rediriger le port 123 vers le container 1
$IPTABLES -t nat -A PREROUTING -p tcp --dport 123 -d $WAN_IP -j DNAT --to-destination $CT2_HOST:123

# Rediriger un port 456 vers le container 2
$IPTABLES -t nat -A PREROUTING -p tcp --dport 456 -d $WAN_IP -j DNAT --to-destination $PAB2_HOST:456

# Activating masquerade FROM local network
$IPTABLES -t nat -A POSTROUTING -o $WAN_IFACE -s $LAN -j MASQUERADE

Exemple de configuration de pound sur l'hôte physique

User		"www-data"
Group		"www-data"
RootJail	"/chroot/pound"

## Logging: (goes to syslog by default)
##	0	no logging
##	1	normal
##	2	extended
##	3	Apache-style (common log format)
LogFacility local0
LogLevel 1

## check backend every X secs:
Alive		180

## use hardware-accelleration card supported by openssl(1):
#SSLEngine	"<hw>"

# poundctl control socket
Control "/var/run/pound/poundctl.socket"

ListenHTTP
	Address 88.123.123.123
	Port	80

	## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
	xHTTP		2

        #Les services à envoyer sur le premier conteneur
	Service
		HeadRequire "Host: .*(domaine1.fr|domaine2.fr|domaine3.fr).*"
		BackEnd
			Address	192.168.0.101
			Port	8080
		End
	End

        #Les services à envoyer sur le second conteneur
        Service
                HeadRequire "Host: .*(domaine4.fr|domaine5.fr).*"
                BackEnd
                        Address 192.168.0.102
                        Port    8080
                End
        End

End

ListenHTTPS
        Address 88.123.123.123
        Port    443
	Cert    "/path/to/certificate/pound.pem"

	HeadRemove "X-Forwarded-Proto"
        AddHeader "X-Forwarded-Proto: https"

        ## allow PUT and DELETE also (by default only GET, POST and HEAD)?:
        xHTTP           2

        #Les services à envoyer sur le premier conteneur
	Service
		HeadRequire "Host: .*(domaine1.fr|domaine2.fr|domaine3.fr).*"
		BackEnd
			Address	192.168.0.101
			Port	8080
		End
	End

        #Les services à envoyer sur le second conteneur
        Service
                HeadRequire "Host: .*(domaine4.fr|domaine5.fr).*"
                BackEnd
                        Address 192.168.0.102
                        Port    8080
                End
        End

End

Monday, October 14 2013

Suivre l'état de son serveur avec Munin

Munin est un logiciel libre performant pour surveiller et suivre ("monitorer" si on s'autorise les anglicismes) des ordinateurs ou des serveurs. Il se compose de deux composants :

  • munin-node, l'utilitaire chargé de récupérer les données sur les "noeuds" du réseau
  • munin, le superviseur qui compile les données de tous les "noeuds" surveillés, fabrique des graphiques et des pages HTML pour permettre la visualisation aisée des données au travers d'un serveur web

Nous allons décrire ici le déploiement de munin-node sur un serveur et de munin sur un poste superviseur distinct.

Installer et paramétrer munin-node sur le poste à surveiller

Munin-node s'installera avec votre gestionnaire de paquet favori ; par exemple sous Debian :

aptitude install munin-node

Lors de l'installation, munin-node choisit et paramètre automatiquement un certain nombre de plugins (chaque plugin est un petit programme autonome capable d'aller collecter des données précises : par exemple le plugin cpu collecte des informations sur la charge du processeur, postfix_mailstats extrait des logs le nombre de courriels transmis par postfix, ...). Le paramétrage de munin-node s'effectue dans /etc/munin/munin-node.conf.

On pourra notamment prêter attention à ces paramètres :

#Spécifier le nom de l'hôte surveillé
host_name serveur_surveille1.domain.tld
#Adresse IPv4 du superviseur qui aura le droit de se connecter au noeud pour récupérer les informations
allow ^192\.168\.1\.200$
#Port sur lequel le service est disponible
port 4949

Une fois le paramétrage terminé, on redémarre le client par la commande

service munin-node restart

Installer le superviseur

Le superviseur Munin s'installe avec :

aptitude install munin

Il faut ensuite indiquer au superviseur quels sont les noeuds à interroger et éventuellement donner des indications spécifiques pour les graphes à construire. Cela s'effectue dans /etc/munin/munin.conf :

[serveur_surveille1.domain.tld]
    address 192.168.1.45
    use_node_name yes

Le travail de génération des graphes et des pages HTML est effectué régulièrement grâce à une tâche cron (dont la fréquence pourra être modifiée dans le fichier /etc/cron.d/munin). Il est également possible de paramétrer le système pour générer les graphes lors des consultations à l'aide d'un recours à des scripts cgi - cela n'est pas détaillé ici. Les travaux de munin ne sont pas silencieux, les logs (bien pratiques pour comprendre une éventuelle panne) sont situés dans /var/log/munin/.

On redémarrer munin par

service munin restart

et après quelques minutes d'attente, les premiers graphes doivent être générés et accessibles dans /var/cache/munin/www/.

On pourra alors rendre accessible ce dossier au travers d'un serveur web bien paramétré !

Load munin

Pour aller plus loin avec les plugins sur le noeud

Tous les plugins disponibles sont regroupés dans /usr/share/munin/plugins/ et on pourra les rendre actifs par la commande :

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

Pour tester un plugin et visualiser les données qu'il retourne, on pourra utiliser la commande :

munin-run postfix_mailstats

La configuration des plugins s'effectue dans le fichier /etc/munin/plugin-conf.d/munin-node suivant les instructions que l'on trouvera dans les en-têtes des fichiers de plugins.

Bonne surveillance de vos serveurs !

page 3 of 3 -