lindev.fr

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - administration

Fil des billets - Fil des commentaires

23 fév. 2013

Linux LTSP : Restriction web par utilisateur

juanjo_Firewall.svg

J'administre aujourd'hui un serveur LTSP ( entre autres ) sur lequel se connectent une bonne quinzaine de clients.

Pas de problème jusque là, mais une problématique est apparue, en effet les clients n'ont pas tous les mêmes droits au niveau des accès vers l'extérieur ( le Net ).

Certains doivent avoir accès à 100% au net, d'autres ont le droit d’accès à l'intranet ou apli métier web uniquement .

Les clients se trouvant tous sur le même serveur, il m'est évidemment impossible de gérer celà depuis le Firewall principal.

Je vais donc exposer ici la solution qui me permet de gérer mes clients de façon simple et efficace .

La solution netfilter

le module netfilter ipt_owner va nous permettre de créer des règles de filtrage qui utilisent l'une des variables suivantes

  • UID
  • GID
  • PID
  • SID

Top ! voyons comment le mettre en place

Activer ipt_owner

L'activation est simple, il suffit d'activer le module ( s'il ne l'est pas déjà ) grâce à la commande modprobe

modprobe ipt_owner

info.png Pour l'activer automatiquement au démarrage, il vous suffit d'ajouter le nom du module dans le fichier /etc/modules


Les règles iptables

Voici les options disponibles pour les règles iptables

#Iptables' owner match extension adds four match criteria to the iptables command:
-- uid-owner UID: matches packets generated by a process whose user ID is UID
-- gid-owner GID: matches packets generated by a process whose group ID is GID.
-- pid-owner PID: matches packets generated by a process whose process ID is PID.
-- sid-owner SID: matches packets generated by a process whose session ID is SID.

Le script de règles

Pour faire les choses bien, nous allons commencer par créer un fichier shell pour éditer et activer simplement l'enssemble des règles

vim regles_ltsp.sh

Le contenu :

#!/bin/sh

#Supprime l'enssemble des régles
iptables -F

#Accepte les requêtes en loopback
iptables -A OUTPUT -o lo -j ACCEPT

#On autorise les requêtes sur le réseau local ( intranet applis metier )
iptables -A OUTPUT -o eth0 -d 10.0.0.0/24 -j ACCEPT

#Compte autorisés à aller sur le net
iptables -A OUTPUT -o eth0 -m owner --uid-owner cdsl -j ACCEPT
iptables -A OUTPUT -o eth0 -m owner --uid-owner root -j ACCEPT

#Groupe(s) autorisés à aller sur le net
#iptables -A OUTPUT -o eth0 -m owner --gid-owner net -j ACCEPT

#On bloque les autres
iptables -A OUTPUT -j DROP

On le rend exécutable

chmod +x regles_ltsp.sh

Les commentaires sont assez clair, on bloque tout, puis seuls les utilisateurs cdsl et root sont autorisés à sortir, ainsi que les utilisateurs du groupe net.

Ainsi pour autoriser un autre utilisateur sans toucher / recharger les règles iptables, il suffira de l'ajouter au groupe net

adduser <user> net

Cool !

Bien maintenant comment charger automatiquement nos règles au démarrage du système et de façon efficace.

Chargement automatique

iptables est fournit avec deux commandes très pratiques

  • iptables-save
  • iptables-restore

qui permettent respectivement de "compiler et extraire" les règles actuellement en cours , et de restaurer des règles sauvegardées avec iptables-save

Commençons par activer nos règles, car pour le moment nous avons uniquement créé le script mais nous ne l'avons pas exécuté . Pour voir les règles actuellement en place nous pouvons utiliser la commande iptable -L

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Aucune règle pour le moment.

On exécute notre script ( en root )

./regles_iptables.sh
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             10.0.0.0/24         
ACCEPT     all  --  anywhere             anywhere            owner UID match root 
ACCEPT     all  --  anywhere             anywhere            owner GID match net 
DROP       all  --  anywhere             anywhere            

Magnifique !

Sauvegardons nos règles

Nous allons les sauvegarder dans le fichier ( en root ) /etc/iptables.up.rules

iptables-save > /etc/iptables.up.rules

Puis nous allons créer un petit script pour appliquer les régles juste avant de connecter les interfaces réseaux

vim /etc/network/if-pre-up.d/iptables

Voici le contenu, qui utilise la commande iptables-restore

#!/bin/bash
/sbin/iptables-restore < /etc/iptables.up.rules

Et on le rend exécutable

chmod +x /etc/network/if-pre-up.d/iptables

info.png Pour effacer l'enssemble des régles, utiliser la commande iptables -F


Conclusion

Et voilà comment gérer vos règles iptables simplement et proprement au démarrage, en ayant la possibilité de filtrer par utilisateur ou groupe d'utilisateurs.

Bon tests . Ch.

04 déc. 2012

RaspberryPi Client LTSP

red-raspberry-isp.jpg

L'Histoire

J'ai présenté il y a peu une solution pour utiliser rapidement la raspberry en client LTSP, grâce à BerryBoot et Berryterminal, bien que fonctionnant correctement, je n'étais pas satisfait d'autant qu’après la mise à jour de BerryBoot sur mes cartes, j'ai constaté des problèmes réseau ( ralentissement ... Freeze .. reprise accéléré comme si l'affichage rattrape ce qui s'est passé pendant le freeze .. étonnant ).

Je vais donc partager avec vous une méthode pour palier à ce problème.

La solution

Je me suis finalement décidé à configurer les clients LTSP, en ma basant sur une Raspbian dernière version .

Après l'installation classique avec l'outil DD, j'ai configuré les locales, keymap, optimisé le système de fichier ext3 , et bien entendu désactivé les modules non nécessaires .

LTSP Display Manager

LDM est le gestionnaire de session X à distance, utilisé par LTSP ( depuis la version 5 ), il nous faut donc simplement l'installer

apt-get install ldm

Remote X

Il ne reste plus qu'à créer un script au démarrage permettant d'ouvrir le tunnel SSH et enfin executer la session X à distance . Bref, LDM

Je me suis donc basé sur le script de berryterminal, qui avec un peut d'adaptation, s'est parfaitement adapté au système.

Commençons par éditer un fichier nommé ldmX dans /etc/init.d/

vim /etc/init.d/ldmX

Voici le contenu

#!/bin/bash
#
# Quick & dirty LTSP startup script
# Author: Floris Bos
#
export GDM_KEYBOARD_LAYOUT=fr
export LC_ALL=fr_FR.UTF-8
export LANG=french
export XKBMODEL="pc105"
export XKBLAYOUT="fr"
export XKBVARIANT=""
export XKBOPTIONS=""



case "$1" in
  start)
    export DISPLAY=:0
    export LDM_THEME=ltsp
    export LANG=fr_FR.UTF-8
    export LANGUAGE=fr_FR.UTF-8
    export LDM_LANGUAGE=fr_FR.UTF-8
    #export LDM_DIRECTX=True
    export LDM_LANGUAGE="fr_FR.UTF-8"
    # FIXME: should introduce a way to embed keys in image to prevent man-in-the-middle scenario
    export LDM_SSHOPTIONS="-o StrictHostKeyChecking=no -o CheckHostIP=no"

    # LTSP acts as DHCP server.  /usr/share/uhdcpc/default.script has been modified to save server IP in /tmp/siaddr
    LDM_SERVER=`cat /tmp/siaddr`

    # If there is a "server=1.2.3.4" kernel parameter use that instead
    for x in `cat /proc/cmdline`
    do
        case $x in
            server=*)
            LDM_SERVER=${x//server=}
            ;;
            autologin=*)
            LDM_AUTOLOGIN=${x//autologin=}
            ;;
            username=*)
            LDM_USERNAME=${x//username=}
            ;;
            password=*)
            LDM_PASSWORD=${x//password=}
            ;;
        esac
    done
    export LDM_SERVER
    export LDM_AUTOLOGIN
    export LDM_USERNAME
    export LDM_PASSWORD

    echo "Retrieving LDM settings from ${LDM_SERVER}"
    mkdir /var/run/ldm
    nc -w 5 ${LDM_SERVER} 9571 > /var/run/ldm/${LDM_SERVER}

    if [ ! -s /var/run/ldm/${LDM_SERVER} ]; then
        echo "Error retrieving LDM settings from ${LDM_SERVER}. Not a LTSP server?"
        exit 1
    fi

    MCOOKIE=$(mcookie)
    xauth -q add ${DISPLAY} . ${MCOOKIE} 2>/dev/null
    echo "Starting X"
    Xorg &
    while true
    do
        ldm
        echo "Restarting LDM"
        sleep 1
    done
    ;;

  *)
    exit 0
esac

exit $?

On le rend exécutable, puis on l'ajoute à l'init au démarrage

chmod +x /etc/init.d/ldmX
cd /etc/init.d/
update-rc.d ldmX defaults

cmdline.txt

Pour paramétrer l'autologin, ou l'ip du serveur LTSP, vous devrez éditer le fichier cmdline.txt, et y spécifier les paramètres suivants

  • server=x.x.x.x
  • autologin=True|False
  • username=Foo
  • password=Bar

Conclusion

Vous voilà avec un client LTSP qui vous a couté 29E ! Et les tests de stabilités réseau semblent passer sans problème .

Je peux transmettre l'image finale pour ceux que ça intéresse.

Ch.

08 oct. 2012

App Node.js persistante

Nous allons voir dans ce billet comment rendre votre application Node.js persistante dans le temps, c'est à dire

  • Démarrer l'app automatiquement au démarrage du système
  • Restart en cas de crash du process
  • ...

Les dépendances

Pour mener à bien cette fonction, nous allons utiliser le module forever

Installation en tant que module global ( disponible depuis n'importe quelle app )

sudo npm -g install forever


Je travail actuellement sur la version 0.8.11 de Node.js et la version 0.10.0 de forever

Capture_d_ecran_2012-10-08_a_13.10.46.png

Capture_d_ecran_2012-10-08_a_13.10.19.png



init.d

Nous allons créer un script de démarrage ( définition de service ) pour notre application

cd /etc/init.d
vim MonAppNode

Voici le contenu :

#!/bin/bash

# Source function library.
. /lib/lsb/init-functions

#############PARAMETRES A CONFIGURER################

NAME=app.js                 # Nom de votre application
PORT=1234                   # Port (dans le cas ou votre app utilise process.env.PORT pour définir le port)
INSTANCE_DIR=/var/nodelab/monappnode/$NAME         # emplacement de votre application
SOURCE_NAME=MonAppNode       # Nom donné au process

user=www-data
pidfile=/var/run/$SOURCE_NAME.pid
logfile=/var/log/$SOURCE_NAME.log
forever_dir=/var/run/forever # chemin d'execution de forever.

###################FIN#########################

export PATH=$PATH:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/game

node=node
forever=forever
awk=awk

start() {
    echo "Starting $NAME node instance: "

    if [ "$id" = "" ]; then
        # Create the log and pid files, making sure that the target use has access to them
        touch $logfile
        chown $user $logfile

        touch $pidfile
        chown $user $pidfile

        # Launch the application
        start_daemon
            $forever start -p $forever_dir --pidFile $pidfile -l $logfile -a -d $INSTANCE_DIR $SOURCE_NAME
        RETVAL=$?
    else
        echo "Instance already running at pid $id"
        RETVAL=0
    fi
}

restart() {
    echo -n "Restarting $NAME node instance : "
    if [ "$id" != "" ]; then
        $forever restart -p $forever_dir $id
        RETVAL=$?
    else
        start
    fi
}

stop() {
    echo -n "Shutting down $NAME node instance PID : `cat $pidfile` "
    if [ "$id" != "" ]; then
        $forever stop -p $forever_dir $id
    else
        echo "Instance is not running";
    fi
    RETVAL=$?
}

status(){
    pid=`cat $pidfile`
    $forever list -p $forever_dir | $awk "\$8 && \$8 == \"$pid\" { print \$0; };"
    #forever list -p /var/run/forever | awk '$8 && $8 == "27567" { print $0; };'
}

getForeverId() {
    pid=`cat $pidfile` 
    $forever list -p $forever_dir | $awk "\$8 && \$8 == \"$pid\" { gsub(/[\[\]]/, \"\", \$2); print \$2; };"
    #forever list -p /var/run/forever | awk '$7 == "27270" { gsub(/[\[\]]/, "", $2); print $2; };'
}
id=$(getForeverId);


case "$1" in
    start)
        start
        ;;
    stop)
        stop
        ;;
    status)
        status 
        ;;
    restart)
        restart
        ;;
    *)
        echo "Usage:  {start|stop|status|restart}"
        exit 1
        ;;
esac
exit $RETVAL

On le rends exécutable

chmod +x MonAppNode

Enfin on déclare le service dans init.d

update-rc.d MonAppNode defaults

Utilisation

Comme chaque script de démarrage, il répond aux commandes

service MonAppNode start
service MonAppNode stop
service MonAppNode status
service MonAppNode restart

Pour ce qui est de la surveillance du process node, tout est gérer par forever .

Conclusion

Voilà une méthode parmi d'autres, le script ci-dessus a été fait depuis une version plus ancienne trouvé sur le net ( je ne sais plus ou désolé ) que j'ai adapté .

Ch.

12 juil. 2012

LTSP V5 et Debian Squeeze

logo-ltsp.png

LTSP ( Linux Terminal Server Project )

J'ai pour mission d'informatiser une zone de production de prés de 7000m2, après le câblage de la zone ( RJ45 10/100/1000 ), il m'a fallu trouver un moyen économique / facile à maintenir et surtout résistant à un environnement de production.

Installer des machines autonomes ( PC standard ) n'est donc pas la meilleure solution.

J'ai donc opté pour un système client-serveur, ou les clients dit (léger) n'ont besoin que d'une interface réseau compatible PXE, et d'une carte/chip. graphique pour l'affichage sur l’écran. ( et évidemment , le trio Ecran/clavier/souris ).

Pour ce qui est de la puissance nécessaire, la station gérant uniquement l'affichage ( dans mon cas ) un cpu type atom peut suffire ( C'est l'occasion de recycler les vielles machines qui trainent), n'importe quel client léger peut faire l'affaire .

Je parle, je parle , mais c'est quoi exactement LTSP ....

le principe est simple, d'un coté il y a un serveur ( relativement puissant, cette variante va dépendre du nombre de clients à gérer ), sur lequel vous devrez créer les comptes utilisateurs. De l'autre les clients léger, qui ne sont là que pour déporter l'affichage de la session utilisateur, enfin entre les deux parties un réseau 100/1000.

Plusieurs avantages à ce principe:

  • installation ou mise à jour à un seul endroit, pour l'enssemble des clients
  • Maintenant aisé ( juste un remplacement de matériel, pas de restauration necessaire )
  • Backup simplifié ( une seule origine )

Le Fonctionnement

Avant de vous expliquer comment monter un tel serveur, je vais vous présenter rapidement comment cela se passe entre le client et le serveur.

Commençons par un petit schéma de notre infra .. j'adore les schémas

ltsp-1.png

Nous avons donc un réseau avec un parc de clients légers, un serveur DHCP déjà existant, et enfin notre serveur LTSP, le tout, évidemment relié à l'aide d'un concentrateur de qualité 10/1000/1000.

Bon très bien, quand j'appuie sur le bouton "power" de mon client léger ... il se passe quoi

ltsp-2.png

Bon , détaillons tout ça ..

  1. La carte mère est alimentée, elle détecte ses périphériques, le bios indique que le boot commence via le LAN , ok je balance donc sur le réseau une requête afin que quelqu'un me réponde avec une IP à me donner et les instructions nécessaires à mon Boot système.
  2. Notre serveur DHCP reçoit évidemment cette requête ( comme toute les autres machines présentes sur le réseau ) lui attribut une adresse IP libre ainsi que les paramètres supplémentaires ( Adresse sur Serveur LTSP, Fichier image à charger ... ) que nous détaillerons plus tard
  3. Super nous voilà connecté et identifié sur le réseau, nous pouvons maintenant contacter le serveur LTSP et charger le fichier image via le protocole tftp ( ftp en mode udp )
  4. Le fichier image reçu ( avec les fichiers de conf qui vont avec ), il est chargé en mémoire ( en RAM ) et on continue notre chemin en lançant le système fraichement chargé .
  5. Le système chargé ( distribution debian minimaliste ) nous avons droit à un superbe écran de connexion ( graphisme customisable au passage ). Bien! identifions nous .. login ... mot de passe, notre système minimaliste tente donc à distance de se connecter avec le couple login mot de passe ( tout se fait en SSH, donc rien ne passe en clair à ce moment sur le réseau )
  6. L’authentification réussi on peut voir sur notre client léger, la session (Gnome par exemple) s'afficher. Il nous est alors possible de lancer n'importe quelle application avec la puissance du serveur, tout en étant sur une machine de plus de 10 ans.

Voilà grosso modo comment cela fonctionne avec LTSP . Bien! nous allons maintenant pouvoir aborder la mise en place du serveur, avec plus de facilité.

Environnement Graphique

Et oui .. fatalement il nous faut un environnement graphique sur notre serveur .. n'en n'ayant jamais installé sur aucun de mes serveurs, il m'a fallu commencer par là ...

apt-get install gnome gdm

Continuons ...

LTSP Server

Deux solutions s'offrent à nous à ce stade, soit nous installons le paquet ltsp-server-standalone, soit le paquet ltsp-server ...

Quelle est la différence vous aller me dire ...

C'est très simple, le paquet ltsp-server-standalone est un paquet "tout en un" c'est à dire qu'en plus de vous installer le serveur ltsp, il va aussi installer un serveur DHCP, et TFTP . Ayant dans mon cas un serveur DHCP en place, je vais installer le second paquet ltsp-server.. ( si vous n'en n'avez pas, installer le premier, la seule différence va être que votre DHCP sera sur la même machine que le serveur LTSP ).

Donc ( avec les paquets suggérés ):

apt-get install ltsp-server dnsmasq libasound2-plugins ltspfs ldm-server sdm pulseaudio-esound-compat esound-clients nas-bin ltsp-docs qemu-user-static syslinux-common

Système de fichier NFS

Le système de fichier de notre distribution minimaliste étant situé sur le serveur LTSP ( il n'est pas chargé en RAM ), ce dernier est monté nia NFS, il nous faut donc l'installer et configurer le fichier /etc/exports afin d'y ajouter le répertoire contenant notre système de fichiers.

apt-get install nfs-kernel-server
vim /etc/exports

Nous allons y ajouter la ligne suivante

/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

Nous pouvons ensuite relancer le service NFS

invoke-rc.d nfs-kernel-server restart

Tftp

Tout à l'heure j'ai parlé du serveur TFTP, utiliser par le client PXE pour charger le noyau minimaliste, et les quelques fichiers de conf ..

Installons le :

apt-get install atftpd

La configuration par défaut n'est pas valide, nous allons donc le reconfigurer.

Commençons par supprimer la ligne suivante du fichier /etc/inetd.conf

tftp            dgram   udp4    wait    nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /srv/tftp

Puis reconfigurons le

dpkg-reconfigure atftpd

Gardez toutes les valeurs par défaut, sauf au moment ou il vous demande de spécifier la plage réseau ( indiquer la votre )

atftpd.png

Enfin, nous pouvons le relancer ...

invoke-rc.d openbsd-inetd restart

Ip Forwarding

Notre serveur va relayer les paquets de nos clients léger, nous devons donc activer l'ip forwarding

Pour le faire en "one shoot", sans redémarrer

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

Et pour que ce soit ... durable

mettez à 1 le paramètre net.ipv4.ip_forward du fichier /etc/sysctl.conf

L'image minimale

Bien maintenant que tout nos services sont Ok, on va pouvoir créer notre image minimale ainsi que le système de fichier, qui sera utiliser par notre client léger.

Pour accomplir cette tâche nous allons utiliser la commande

ltsp-build-client --arch i386 --chroot classique
  • --arch permet de spécifier une architecture pour notre client ( attention à ne pas l'oublier si votre serveur tourne avec une debian 64Bits et votre client en 32, par défaut l'architecture du serveur sera utilisé, tout comme la version du noyau linux à charger )
  • --chroot permet de nommer notre environnement minimaliste, par défaut le nom de l'architecture est utilisé "i386" ( vous noterez qu'il est possible d'utiliser plusieurs images différentes, avec des noms différents pour tel ou tel client léger )

Je vous laisse le loisir de parcourir la page de man de la commande pour le reste des paramètres, qui permettent par exemple de charger un noyau linux de la branche unstable, ou testing ou autre ... bref mettre la version de vôtre choix ( par défaut elle est identique à celle du serveur , squeeze dans mon cas ).

Une fois terminé, nous allons mettre à jour les clefs SSH entre notre serveur et l'environnement fraichement créé ( utilisé pour la liaison réseau client - serveur )

ltsp-update-sshkeys

DHCP

Et oui je ne vous ai pas encore parlé de cette partie essentiel au bon fonctionnement .

Comme nous l'avons vu, un client léger commence par chercher un serveur DHCP sur le réseau pour passer à la suite.

Dans mon exemple, le serveur LTSP possède l'adresse 10.0.0.221, et le serveur DHCP 10.0.0.8

Afin de structurer la configuration au niveau du DHCP, nous allons créer un fichier spécifique pour les clients léger , puis le déclarer dans le fichier de configuration principale du serveur DHCP

Commençons par créer ce fameux fichier

touch /etc/ltsp/dhcpd.conf

Puis on le déclare dans notre configuration principale du DHCP

vim /etc/dhcp3/dhcpd.conf

Et on y ajoute à la fin :

include "/etc/ltsp/dhcpd.conf";

Bien, revenons au contenu du fichier /etc/ltsp/dhcpd.conf

Nous allons créer un groupe afin de pouvoir déclarer des paramètres pour l’ensemble des clients, voici un exemple que vous pouvez utiliser en adaptant les ip et adresses MAC:

group {
#Système de fichier à monter
option root-path "/opt/ltsp/classique";
#Adresse du serveur LTSP
next-server     10.0.0.221;
#Fichier image à charger
if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
filename "/ltsp/classique/pxelinux.0";
} else {
filename "/ltsp/classique/nbi.img";
}
#Client leger Dell
host pxeDell {
hardware ethernet 00:14:0b:80:e5:1a;
fixed-address   10.0.0.101;
}
#Client leger HP
host pxeHP {
hardware ethernet 00:16:17:5e:57:ec;
fixed-address   10.0.0.102;
}
#Client de test
host pxeTest {
hardware ethernet 00:14:67:e5:57:ab;
fixed-address   10.0.0.103;
filename "/ltsp/unstable/pxelinux.0";
option root-path "/opt/ltsp/unstable";
}
}

Dans ce groupe nous commençons par spécifier le système de fichier par défaut à monter, l'image à charger et l'adresse du serveur LTSP , vient ensuite la déclaration des clients PXE, identifié par un nom , une ip et une adresse MAC.

Il est possible de spécifier une autre image ou un autre système de fichier à monter pour un poste particulier, ex : host unstable qui chargera l'image nommée unstable ( souvenez-vous , l'option --chroot de la commande ltsp-build-client )

Nous n'avons plus qu'à redémarrer notre serveur DHCP, et tester avec un des client léger paramétré ci-dessus.

invoke-rc.d dhcp3-server restart

Premier Test

Il suffit d'appuyer sur le bouton "power" et normalement .... vous devriez découvrir ceci

N'hésitez à poster vos commentaires sur le sujet, nous verrons dans le prochain article, comment monter une clef usb ou un CD à partir du client léger, ou encore y faire passer le son, nous verrons aussi comment configurer les client PXE de façon globale ou pour un client unique.

Bref ... vous n'avez pas fini avec ce sujet :) restez à l'écoute .

Ch.

27 mai 2011

LVM exemple de mise en pratique

recuperation-donnees-fichiers-9.jpg Cela fait longtemps que je tourne autour de ce gestionnaire de volumes jamais avoir eu l'occasion d'y mettre les mains . Aujourd'hui c'est chose faite !

LVM / LVM2 utilisation

Il y a quelques jours j'ai eu pour mission la mise en production d'un serveur web linux, hébergé sur une plateforme de virtualisation microsoft Hyper-V. Le contrainte principale était bien entendu la disponibilité de ce serveur , mais aussi la possibilité de restaurer le serveur sans connaissance particulière et surtout en un temps record ..

Première possibilité ,

La mise en place d'un cluster ( soit , deux machines virtuelles en front ou une maitre et l'autre esclave ). La machine hôte ( Hyper-V ) étant déjà bien chargé , la mise en place d'une seconde VM n'était pas envisageable.

Seconde possibilité ,

La machine hôte étant associée à une baie SAN, nous avons donc migré les données variables ( sources et BDD ) sur cette dernière , ce qui rend la restauration de la machine virtuelle aussi simple qu'un "copier coller", à partir du moment ou la vm est sauvegardé.

Pourquoi LVM

J'y viens, mettre les données dynamiques sur la baie SAN est bien beau , mais figer une taille de disque ( aussi virtuel soit-il ) est assez délicat. A moins d'être devint, il est très difficile d'estimer une taille suffisamment grande pour supporter les éventuelles évolutions, et il serait vraiment dommage de gâcher de de l'espace disque en surestimant le besoin .( l'espace disque SAS est à utiliser avec parcimonie, le moindre Go de cette qualité est précieux ).

J'ai donc créé un disque virtuel d'une taille fixe de 5Go ( il est aussi possible de créer un disque à taille variable , mais les performances chutent de 30% selon la doc ... ). 5Go est bien assez pour commencer et être tranquille un bon moment ( plus ou moins long selon l'activité ).

Ce disque virtuel nommé sdb ( que nos pouvons comparer à un disque dur physique ), sera dans un premier temps formaté, et nous allons créer une partition primaire sdb1 .

Création de la partition primaire

cfdisk /dev/sdb

Maintenant, étant donné que je souhaite utiliser ce disque avec LVM, il est nécessaire de déclarer la partition fraichement créée

Déclaration de la partition sdb1 à LVM

pvcreate /dev/sdb1

Maintenant étape importante, créer le groupe de volume(s) GV. Ce groupe de volume peut être représenté comme une unité regroupant un ensemble de volumes , ou plus simplement expliqué , une grosse partition composée de une ou plusieurs partitions de niveau inférieur appartenant ou non au même disque dur . Ce ne sera plus à vous de gérer la répartition de vos données sur entre les différentes partitions , le GV s'en chargera pour vous.

Création du GV ( Groupe de volumes )

vgcreate MONGROUP /dev/sdb1

Nous voilà maintenant avec un superbe groupe de volumes nommé MONGROUP sur lequel nous allons créer nos volumes logiques LV ( pour les utiliser comme des partitions standard )

Création d'une partition LV ( Volume Logique )

lvcreate -n mapartition -L 4,95g MONGROUP

warning.png Attention à mettre une taille valide, elle ne doit en aucun cas être supérieur à l'espace disponible ( risque de pertes ).

La partition maintenant créée, dernière étape avant de l'exploiter, le formatage .

Formatage de la partition mapartition

mkfs -t ext4 /dev/MONGROUP/mapartition

Et voilà notre volume prêt à l'emploi .

Ne reste plus qu'à le monter .. et l'exploiter ..

mount -t ext4 /dev/MONGROUP/mapartition /mnt

Je vous vois déjà venir en me disant .. que jusqu'à maintenant .. il n'y a pas d'avantage à utiliser LVM ... C'est vrai , créer simplement une partition et la formater directement serait tout aussi performant et bien plus rapide à mettre en place ..

Ok, alors le temps passe et tout d'un coup vous recevez mail de votre client indiquant avoir reçu plusieurs alerte concernant l'espace disponible sur le disque .. aïe !

Pas de panique puisque vous avez pris la peine de créer une partition géré par LVM, dans notre cas il suffira d'augmenter la taille de notre disque virtuel ( ou d'en créer un second ) et de l'ajouter à notre groupe de volumes MONGROUP

Augmenter la capacité du volume

Voyons comment faire cette manip en 5 minutes.

Dans un premier temps il faut démonter le volume avec la commande umount

Démonter le volume à modifier

umount /mnt

Puis il nous faut créer une nouvelle partition ( à partir du nouveau disque ou de l'espace disponible sur le disque virtuel sdb 5G de plus )

cfdisk /dev/sdb

info.png La nouvelle partition sera déclarée comme étant sdb2 ( à adapter dans votre cas )

Une fois la partition créée, nous allons la déclarer à LVM

pvcreate /dev/sdb2

Nous allons ensuite étendre notre groupe de volumes ( MONGROUP ) afin qu'il prenne en compte ma nouvelle partition , et de ce fait , offrir autant d'espace en plus.

Extension du groupe de volumes

vgextend MONGROUP /dev/sdb2

Voilà qui est fait. Nous allons vérifier la partition existante avant de la redimensionner

Vérification de la partition existante

e2fsck -f /dev/MONGROUP/mapartition

Une fois terminé, l'étape la plus importante , le redimensionnement de la partition . Pour commencer nous allons redimensionner notre volume logique ( LV ) mapartition

Redimensionnement de mapartition ( LV )

lvresize -L9,95g /dev/MONGROUP/mapartition

warning.png Attention à mettre une taille valide, elle ne doit en aucun cas être supérieur à l'espace disponible ( risque de pertes ).

Enfin, le volume logique redimensionné, reste à redimensionner notre système de fichiers ext4

Redimensionnement du système de fichiers ext4

resize2fs /dev/MONGROUP/mapartition

Et voilà mon espace disque vient d'augmenter de 5Go . Cette opération peut être répété autant de fois que nécessaire .

lvm2.png

Ch.

- page 1 de 5