présente...

 

Chapitre : Section Pro de Léa

par tous les amis de Léa

 

 

Le copyright de chaque article est détenu par son auteur.
Le copyright du livre lui-même est détenu par Léa (Association Loi 1901).
Les articles de ce livre sont diffusés selon la license GPL (GNU General Public License), sauf mention explicite dans l'article.

Copyright (c) 2003 Association Léa.
This documentation is free documentation; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This documentation is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
For the purpose of applying the GPL to this document, I consider "source code" to refer to the html source.


Table des matières


Léa pour les pros !

Cette section contient les chapitres relatifs à une utilisation professionnelle de Linux.

Haut


La Haute Disponibilité

par Benjamin (prae) GIGON

Relecture, correction des fautes et conversion en HTML léalinux par Anne


Statut de ce mémo

Ce document étudie les infrastructures et les différents types et méthodes de haute disponibilité dans un environnement donné. Il présente aussi les différentes solutions en termes logiciels et matériels afin de parvenir à une haute disponibilité. Ce document est une documentation ouverte.

Notice de droit

Ce document est sous licence libre : The GNU Free Documentation License.
Ce document peut-être copié et distribué sans restriction aucune.
Pour de plus amples informations, veuillez vous reporter sur cette page.
Auteur : Benjamin ou Prae
Relecture : Anne
Groupe : Recherche et Développement Sherpadown

Introduction

Dans le monde du clustering il existe 2 types de clusters : le cluster de calcul et le cluster de haute disponibilité. La solution qui nous intéresse est celle de la haute disponibilité.

Dans une architecture à haut risque où les services doivent être disponibles 24 heures sur 24, 7 jours sur 7, une solution devrait être en mesure d'assurer cette disponibilité. Cette solution est le "High Availbility" autrement dit "Haute disponibilité".

Le cluster de haute disponibilité est un ensemble de serveurs physiques, au nombre minimum de deux, afin d'obtenir une activité de services par tous temps, en toutes conditions, de l'ordre du 99.99% (1).

La haute disponibilité possède deux grands axes : La disponibilité des services et la disponibilité des données.

I) La disponibilité des services

Dans l'introduction, vous avez sûrement constaté que je mentionne deux serveurs au minimum. Pourquoi ce minimum ? Tout simplement parce qu'un service interrompu ne veut pas dire que le serveur soit toujours là. Quand un service n'est plus disponible, il ne suffit pas de détecter la panne en elle-même et de redémarrer le service en question, car le problème pourrait être beaucoup plus grave : une indisponibilité de la part du système entier, voire de la machine (problème matériel). C'est pour cela que le deuxième serveur est indispensable.

Pour en revenir à la disponibilité de services, son principe est simple : un service, quelle que soit sa machine de référence (2) ou les données dont il dispose, doit toujours répondre aux clients qui en font la demande. C'est-à-dire que peu importe le serveur qui répond, lorsqu'un client arrive, le service demandé doit satisfaire la demande.

Le serveur répondant est l'un des serveurs du cluster qui est (encore ?) en activité. Dans le cas d'un cluster en haute disponibilité sans load balancing (reportez-vous au chapitre "Load Balancing pour en savoir plus), le serveur maître répond à toutes les requêtes sauf si celui-ci est indisponible. Dans ce cas, c'est le ou l'un des serveurs esclaves qui répond.

Pour de la haute disponibilité de services, deux types de techniques existent : Le FailOver Services et le Linux Virtual Server.

Nous allons commencer par étudier le FailOver Services.

A - Le FailOver Services (FOS)

Le failover services est un processus de monitoring et de reprise de services pour seulement deux machines : Le serveur maître et le serveur esclave, chacun surveillant l'autre sur deux canaux et types de connectiques différents. Dans la plupart des cas, les deux types de liaisons sont de l'ordre du réseau RJ45 en utilisant le protocole TCP/IP et du câble série branché directement sur les deux machines (3). Ces précautions évitent que l'un des serveurs identifie son "compagnon" comme inaccessible alors qu'il n'y a qu'un problème de congestion de réseau ou bien un problème de branchement momentané sur les câbles.

Le FailOver Services peut vérifier tout services utilisant le protocole TCP/IP et commander l'arrêt ou le démarrage de n'importe quels scripts. Ce dernier contrôle aussi l'état réseau des machines : en d'autre terme, le contrôle de l'IP de la machine.

FOS utilise un principe très simple mais à la fois très astucieux dans le changement de serveur "répondant". Il utilise l'IP Aliasing (Appendice A). L'IP Aliasing permet de définir une interface réseau avec plusieurs adresses IP différentes.

Le serveur maître et le serveur esclave possèdent tous deux une adresse IP du même sous-réseau (disons 10.10.11.1 pour le maître et 10.10.11.2 pour l'esclave). L'astuce vient du fait que lorsque le client fait appel à un serveur, il interpelle un serveur possédant une adresse IP Aliasée, c'est-à-dire qu'il n'appelle pas la machine possédant l'adresse IP 10.10.11.1 ou 10.10.11.2 mais disons par exemple 192.168.10.200. Cette adresse IP ne sera pas définie comme IP principale mais comme IP Aliasing. Ainsi lorsque le serveur maître tombe, l'adresse aliasée est redéfinie autre part.

Exemple :

schema un

Lorsque le serveur maître n'a plus de moyen de satisfaire les demandes, le FailOver Services destitue l'IP Aliasé du serveur maître pour le réattribuer sur la machine esclave. (En fait, il désactive l'adresse IP sur l'un pour la réactiver sur l'autre)

schema deux

Ce procédé est à la fois simple et efficace.

Lorsque le serveur maître peut de nouveau répondre aux requêtes (détecté grâce à la première voie et attesté par la deuxième voie), FailOver désactive l'IP Aliasé de l'esclave et la réactive sur le serveur maître.

Pour que ce type de haute disponibilité fonctionne, il faut bien sûr que la machine esclave possède les mêmes services que son homologue maitre. Sinon la haute disponibilité ne fonctionnera pas.

B - Linux Virtual Server

Le Linux Virtual Server effectue le même travail que son homologue FOS mais avec un procédé légèrement différent. En effet, LVS s'appuie sur une architecture de Load Balancer et d'un ensemble de serveurs. Ce qu'il est interessant de voir, c'est que les études des trois cas de Haute disponibilité de services (FOS,LVS,LB) sont complèmentaires pour assurer un système extrêmement performant. Ainsi Linux Virtual Server peut très bien intégrer un procédé FailOver dans ses serveurs de contrôle de Load Balacing.

Exemple d'un cluster LVS simple :

schema trois

Le procédé qu'utilise le redirecteur LVS est simple, grâce à l'un des quatre algorithmes de load balacing. Il redirige les paquets vers les serveurs appropriés en utilisant l'une des quatres méthodes de routage (voir plus bas, 1.C)

Le redirecteur LVS se charge de connaître automatiquement les serveurs disponibles au sein de son propre cluster de serveurs et d'en attribuer la charge à ceux qui en sont capables. Si un serveur devient indisponible, le redirecteur LVS renvoie les différentes requètes vers un autre serveur disponible jusqu'à ce que le serveur faillitaire revienne dans de bonnes conditions (? --FIX PHRASE)

LVS supporte différentes méthodes de routage : la translation d'adresse de réseau (Network Address Translation [NAT]), l'encapsulation d'IP (IP Encapsultation [Tunneling]) et le routage direct.

La translation d'adresse est utilisée spécifiquement pour un réseau privé. Dans cette méthode de routage, toutes les requêtes passent par le routeur principal (Redirecteur LVS). L'ensemble des paquets transitant sur le redirecteur sont réécrits puis renvoyés vers un serveur, ou le client. De cette façon, le réseau privé contenant les serveurs est masqueradé pour les requêtes des clients. Le gros désavantage de ce type de routage est le goulot d'étranglement qui peut se créer au niveau du Redirecteur. En effet, pour une solution d'une vingtaine ou plus de serveurs, le routeur est surchargé de demandes et ne peut plus traiter les informations (5). De plus les serveurs doivent être physiquement dans le même réseau pour que le Redirecteur puisse agir correctement sur le routage.

Si votre souci est celui du lien géographique des serveurs, l'encapsulation peut être une solution. Le procédé ressemble, au début, à la translation d'adresse, si ce n'est que le redirecteur ne traite que les requêtes du client aux serveurs (requêtes entrantes). Les requêtes sortantes sont traitées du serveur au client directement sans passer par le redirecteur. Ainsi les différents serveurs peuvent se trouver n'importe où géographiquement parlant. Avant d'assigner un travail à un serveur, le redirecteur encapsule l'adresse IP du client à l'intérieur de l'adresse du serveur.

L'inconvénient de cette solution peut venir d'une certaine paranoïa du fait que nous envoyons une requête vers un serveur et c'est un autre qui nous répond. (6)

schema quatre

Si vous souhaitez utiliser ce principe mais au sein de votre réseau privé, le routage direct est ce qu'il vous faut. Le routage direct ressemble à peu de chose à la méthode d'encapsulation d'IP, si ce n'est qu'une troisième couche existe entre le client et les routeurs et que le réseau n'est plus public mais privé. Les requêtes sortantes (réponses) vont directement du serveur final au client demandeur. Cependant, les requêtes entrantes passent par deux "filtres" de routeur. Le premier est un simple routeur qui dispatche les requêtes sur une multitude de clusters de routeurs et de routeurs de sauvegarde. A partir de là, la méthode est la même que pour la méthode d'encapsulation d'IP.

schema cinq

Il existe une dernière méthode de routage, mais celle-ci est implantée dans... le DNS. Je vous préviens de suite, cette méthode ressemble plus à du Load Balacing sans contrôle, dans le sens où le DNS ne sait absolument pas si le serveur sous-jacent est en pleine possession de ses activités. La mise en place est relativement simple. Dans le DNS, lors de la définition du nom de domaine, il suffit de rajouter autant de lignes que de serveurs de sauvegarde (Backup Servers) :

		serveur.tld             A       192.168.10.2	; Server 1
		                        A       192.168.10.3	; Server 2
					A	192.168.10.4	; Server 3

Le DNS va donner aléatoirement une addresse IP.
Cette méthode de routage ne permet pas de la haute disponibilité sûre à 100%, elle permet juste de faire un semblant de Load Balacing. Cette méthode est parfois utilisée dans le système du routage direct en place au lieu du lien entre le premier routeur et l'un des clusters.

C - Algorithmes de Load Balacing

Comme je vous l'ai annoncé plus haut, il existe quatre algorithmes différents pour effectuer du Load Balancing. Le plus simple est le "Round Robin" qui consiste à distribuer le travail équitablement entre tous les serveurs. Le suivant est "Least-connexions" qui consiste à distribuer le plus de travail sur les serveurs avec le moins de connexions actives. Dans ce cas, l'IPVS enregistre les connexions actives. Le troisième algorithme, "Weighted round robin" distribue le plus de travail au serveur de grande capacité (Indiqué par l'utilisateur) et enfin le dernier, le "Weighted least-connexions" distribue le plus de travail avec le moins de connexions actives aux serveurs de grande capacité.

D - Conclusion de chapitre

Au début de ce chapitre, je vous ai cité cette phrase "Un service, quelle que soit sa machine de référence ou les données dont ils disposent, doit toujours répondre aux clients qui en fait la demande". ... "quelque soit [..] les données dont ils disposent", cette phrase a toute sont importance dans le domaine de la haute disponibilité. Dans toutes les méthodes de haute disponibilité de services, il existe un problème majeur : les données. En effet, lorsqu'un serveur primaire tombe, le serveur secondaire prend le relais. Mais ce serveur ne possède pas les données du serveur primaire. (et inversement) (notamment pour les serveurs de mail, les bases de données, etc...). Ce qui pourrait être regrettable, ce sont les coupures de données entre les deux serveurs.

schema six

C'est pour cela que l'on va étudier la haute disponibilité de données, ou le partage de données (shared data).

II) La disponibilité des données

Dans ce domaine-ci, il existe deux types de haute disponibilité de données : les données partagées et les données répliquées. Les données partagées le sont dans le domaine du réseau. Les données répliquées appartiennent à deux domaines : celui du réseau (réplication serveur à serveur) ou local (réplication disque à disque). Cependant dans tous ces domaines, un domaine est prédominant : le type de système de fichiers (filesystem). Ce domaine est très lié à celui des types de haute disponibilité de données. Certains systèmes de fichiers sont orientés réseaux (GFS, Intermezzo, DRBD, NFS (7), M2CS, FENRIS, Coda, LVM) ou orientés local (ReiserFS, Ext3, LinLogFS, Raid)

Voici les différents types de systèmes de fichiers répartis par domaine

A - Premières introduction sur les systèmes de fichiers

1) Lan Mirroring

DRBD							[MIRRORING]
Network Block Device (NBD)				[MIRRORING]
NFS							[SHARED]
CodaFS							[SHARED]
ODR : Online Disk Replicator				[MIRRORING]
ENBD : Enhanced Network Block Device			[MIRRORING]
Network RAID 						[MIRRORING]

2) Volume Managers

LVM							[PARTITIONING]
EVMS : Enterprise Volume Management System (émulateur lvm)[PARTITIONING]

3) FileSystem

GFS						[CLUSTERING/JOURNALING]
ReiserFS					[JOURNALING]
Ext3						[JOURNALING]
JFS (IBM)					[JOURNALING]
XFS (SGI)					[JOURNALING]
FENRIS (Timponagos)				[CLUSTERING]
M2CS (Timponagos)				[CLUSTERING]
Intermezzo					[CLUSTERING]
LinLogFS					[CLUSTERING]

4) Autres

RAID								[MIRRORING]

Avant de commencer, voici un tableau récapitulatif sur les différents modes des systèmes de fichiers.

Nom du système de fichier Miroir Partage Partitionnement Par réseau En local Clustering Journaliser
DRBD X     X     X
Network Block Device (NBD) X     X     X
NFS X(a) X   X     X(a)
Coda FS   X   X   X X(a)
Online Disk Replicator (ODR) X     X   X X
Enhanced Network Block Device X     X     X
Network RAID X     X     X
LVM     X X X X X
Enterprise Volume Management     X X X X X
GFS X     X   X X
ReiserFS         X   X
Ext3         X   X
JFS         X   X
FENRIS ? ? ? ? ? ? ?
M2CS ? ? ? ? ? ? ?
InterMezzo X   ? X   X X
LinLogFS X   X X   X  
RAID X       X   X
SAN X(a) X X(?) X   X X(a)

(a) Tout dépend du système de fichiers utilisé sur le serveur

Avant de passer à des exemples concrets et des méthodes d'utilisation de tous ces systèmes de fichiers, un rappel rapide s'impose. De plus, afin de ne pas se disperser pour l'instant, nous allons étudier les systèmes de fichier suivant : DRBD, NBD, NFS, GFS, ReiserFS, Ext3, InterMezzo ainsi que le Raid au niveau matériel.

B - Le Raid dans une solution de haute disponibilité.

Autant vous le dire tout de suite, le raid n'est pas une solution 100% viable dans un système de haute disponibilité. Pourquoi ? Le système devient viable si et seulement si vous êtes sûr que votre serveur ne tombera pas en panne. Le système Raid ne vous aidera que pour un secours disque, c'est-a-dire que lorsqu'un disque ne fonctionne plus correctement, un autre prend le relais. Mais au cas ou le serveur tombe entièrement, le raid ne pourra plus faire grand chose. Malgré tout, le Raid reste une solution très utile et à privilègier lorsqu'on le peut.

Le système Raid possède 6 mécanismes internes.

Mode Linéaire

Ce mécanisme utilise le deuxième disque dur si, et seulement si, le premier disque dur n'a plus assez d'espace disque.Cette solution n'a pas trop d'avantage puisque si un disque dur tombe, toutes les données du dit disque sont perdues.

Mode Raid 0

Ce mécanisme effectue une découpe des données (strip). L'ensemble des données sont dispatchées sur les deux disque durs ce qui permet une nette amélioration des performances d'entrée et sortie. Cependant, comme le mode Linéaire, ce mode n'est pas à utiliser dans un système de haute disponibilité, puisque si un disque tombe, toutes les données sont perdues.

Mode Raid 1

Ce mécanisme effectue un mirror parfait sur autant de disques qu'il y en a de disponibles.

Cette solution est généralement utilisée dans un système de haute disponibilité car il permet la redondance de données sur plusieurs disques avec une nette amélioration des performances en lecture. Par contre, les performances en écriture subissent une dégradation suite à l'écriture sur plusieurs disques. Et afin d'effectuer ces écritures, le processeur est quelques peu utilisé.

Mode Raid 0+1

Ce mécanisme est une sorte de fusion entre le Raid 0 et le Raid 1, les données sont dispatchées sur les disques durs, mais contraitrement au Mode Raid 0, si un disque dur tombe, les données peuvent toujours être récupérées. De plus les gains de performance ne se limitent plus qu'au mode lecture mais au mode écriture aussi. Le processeur, quant a lui, est quelques peu mobilisé lors d'accès lecture/écriture.

Mode Raid 4

Ce mécanisme utilise 3 disques dur mininum. Ce dernier dispatche les données sur les deux disques et écrit les données supplémentaires de parité sur le troisième disque. Cette méthode permet à un disque dur de tomber sans en perdre les données. Cependant, il existe un problème au niveau de l'écriture pour les données de parité : un goulot d'étranglement sur le troisième disque. Chaque modification sur l'un des deux premiers disques oblige le troisième à écrire ou modifier ses données de parité.

Mode Raid 5

Ce mécanisme est similaire au Raid 4, si ce n'est que le problème du goulot d'étranglement n'existe plus car les informations de parité sont ecrites sur chaque disque.


Dans un système de haute disponibilité, les Raid 1, 4 et 5 sont vivement recommandés car il existe toujours un disque de remplacement.

C - Le Ext3 dans une solution de haute disponibilité

Le Ext3 est un système de fichiers journalisé. Il est le remplacant de l'ext2. Ce système de fichiers a évolué principalement à cause des durées souvent trop longues lors d'une vérification du système de fichiers lorsque le serveur n'a pas réussi à démonter proprement les partitions (généralement après un plantage du serveur). Le grand avantage du Ext3 par rapport aux autres systèmes de fichiers est que l'on passe de l'Ext3 à l'Ext2 et inversement sans problème et sans avoir à jouer avec les différentes partitions pour garder ses données.

De plus, en paramétrant correctement son fstab, l'ext2 peut très bien interpréter l'ext3 et vice-versa. (En fait, l'Ext2 et l'Ext3 sont semblables, mis à part que l'Ext3 possède un journal. Si le kernel ne peut lire que l'ext2, il ne prendra pas en compte le journal).

D - Le ReiserFS dans une solution de haute disponibilité

Le ReiserFS est aussi un système de fichiers journalisé. Ce dernier se distingue par le fait qu'il est basé sur une notion d'arbre.

De plus, il gagne en performance pour un nombre important de fichiers dans un même répertoire et en espace pour les petits fichiers (sous d'autres filesystems, chaque fichier prend un block au minimum, tandis que le ReiserFS essaye de caser tout dans un seul si le fichier fait moins d'un block). Ce système de fichiers est efficace mais plus difficilement applicable sur un système déjà existant.

E - InterMezzo dans une solution de haute disponibilité

Le système de fichier InterMezzo est quelque peu différent de ses congénères (vus au dessus). InterMezzo permet une réplication par réseau des données. Il intégre une gestion de déconnexion (si l'un des serveurs de sauvegarde est indisponible, il sera resynchronisé plus tard) et gère l'Ext3, le ReiserFS et le XFS pour l'instant. InterMezzo s'inspire du fonctionnement de Coda (voir plus bas ou Appendice B) Très utile dans un système de haute disponibilité, son grand désavantage, c'est qu'il est encore en développement à l'heure actuelle.

F - The Network Block Device (NBD) dans une solution de haute disponibilité. (C)

Network Block Device reprend le principe d'InterMezzo et de Coda, dans le sens où il effectue une copie conforme d'un serveur à un autre serveur au moyen du réseau. A la seule différence qu'il n'utilise que Ext2 et NFS nativement.

G - Network File System (NFS) dans une solution de haute disponibilité

Le NFS procède différemment d'InterMezzo, Coda et autres NBD car il n'effectue pas une réplication de données mais plutôt un partage de données (data shared). Le système de données ne se trouve pas sur les serveurs de services mais sur un autres serveur dédié ou pas à ce travail. Le gros point noir de NFS est la sécurité : les discussions entre le serveur et son client ne sont pas protégées et les permissions laissent à désirer.

Une solution envisageable consiste soit à utiliser du Tunneling soit à utiliser directement sNFS (Secure Network File System) Cette solution est, malgré tout, recommandé dans certaines solutions de haute disponibilité.

H - Global File System (GFS) dans une solution de haute disponibilité (B)

J'ai trouvé cette définition tellement bien faite, que je vous la donne directement :

"Global File System (GFS) est un système de fichiers sous Linux permettant de partager les disques d'un cluster. GFS supporte la journalisation et la récupération de données suite à des défaillances de clients. Les noeuds de cluster GFS partagent physiquement le même stockage par le biais de la fibre optique ou des périphériques SCSI partagés. Le système de fichiers semble être local sur chaque noeud et GFS synchronise l'accès aux fichiers sur le cluster. GFS est complètement symétrique ce qui signifie que tous les noeuds sont équivalents et qu'il n'y a pas un serveur susceptible d'être un entonnoir ou un point de panne. GFS utilise un cache en lecture écriture tout en conservant la sémantique complète du système de fichiers Unix.

Tout est dit sur ce système de fichiers, mis à part que GFS s'adresse directement aux personnes ayant les moyens car la fibre d'optique ou les périphériques SCSI ne sont pas bon marché. Hormis ce problème, GFS est un atout indispensable dans une solution de haute disponibilité mais surtout dans le cadre d'un Cluster.

I - DRBD dans une solution de haute disponiblité

DRBD, comme InterMezzo et NBD, effectue un replica parfait du disque primaire sur un autre disque dur d'un serveur tiers par voie réseau. DRBD est indépendant du type de système de fichiers utilisé sur le serveur. Vous pouvez donc utiliser n'importe quel système de fichiers.

Tout comme ses congénères, DRBD propose deux types de synchronisation : partielle ou totale. La synchronisation partielle n'effectue une mise à jour du disque secondaire que dans les parties non synchronisées (si le serveur a planté par exemple, rien ne sert de refaire une copie du disque primaire). La synchronisation totale, elle, effectue une copie disque à disque complète, comme si le disque secondaire venait d'être installé.

J - SAN/NAS dans une solution de haute disponiblité

SAN (Storage Area Network) et NAS (Network Attached Storage) sont des serveurs dédiés au stockage de données. Toutefois, SAN et NAS sont différents mais complémentaires. En effet les deux types peuvent être utilisés en même temps pour un service de haute disponibilité. Le NAS se charge du réseau et SAN se charge des serveurs de données. SAN utilise un protocole SCSI tandis que NAS utilise un protocole IP.

SAN est plus une extension pour serveur alors que NAS est plus dans une optique réseau. SAN est plus rapide du fait de sa connectique alors que son homologue NAS améliore grandement le modèle de stockage. Je vous conseille pour plus d'informations, la référence sur SAN/NAS dans l'Appendix B.

Tableau de comparaison :

NAS SAN
Réseau Réseau déjà existant Réseau spécialisé (Fibre Channel)
Fonction unité de stockage Serveur de fichiers Serveur de ressources de stockage
Protocole Type message (NFS over TCP/IP) Type I/O SCSI
Bande passante Dépendant du type (Eth : 10-1000 Mbits/s) Avec Fibre Channel : n * 1 Gbits/s
Administration Stockage administré à travers le serveur de fichiers Administration directe incluant l'infrastructure SAN

K - CodaFS dans une solution de haute disponibilité

CodaFS est un système de fichiers de répartition et de distribution (un peu comme NFS) mais qui intègre des performances et des options aux tolérances de pannes et de sécurité. CodaFS permet une réplication de données, une émulation sémantique et une sécurité accrûe en utilisant les ACLs. Pour en savoir plus sur Coda, je vous conseille de lire la documentation indiqué dans l'Appendice B : CodaFS

III) De la théorie à la pratique

Dans cette partie, nous allons voir comment utiliser ces différents systèmes de fichiers (même ceux non décrits ci-dessus). Nous n'allons pas réellement passer à la pratique, mais plutôt nous en approcher à l'aide de schémas et d'exemples concrets. Les exemples décrits ci-dessous ne sont pas exhaustifs. Il existe de nombreuses possibilités de haute disponibilité à partir des ces bases.

A - Solution de Partage

Les solutions de partage sont simples : les données se trouvent sur l'un des serveurs et les autres serveurs peuvent atteindre ces mêmes données. Pour une solution de haute disponibilité, les données ne peuvent pas se trouver sur l'un des serveurs-services, tout simplement parce que les données seront indisponibles pour les autres serveurs si celui-ci tombe. C'est dans cette optique qu'un serveur est disponible uniquement pour les données. Généralement, ce type de solution combine au minimum trois serveurs : deux de services (un primaire, un de sauvegarde) et un serveur de données.

schema sept

Pour ce type de partage, il n'existe, sauf erreur de ma part (8), que NFS, Samba (dans une certaine mesure), GFS et SAN/NAS qui permettent de faire ceci. Les données sont accessibles par les deux serveurs de services. Si l'un des deux tombe, l'autre est en mesure de lire et de continuer d'écrire sur le serveur de données.

Si le serveur de données tombe, il n'existe qu'un seul moyen : la réplication.

B - La réplication

1) La réplication en local

La réplication locale est une réplication qui s'effectue sur le serveur même et non sur un serveur tiers. Ce mode de réplication peut très bien être ajouté dans une réplication par réseau déjà existante.

Dans cette solution, le Raid est souvent utilisé. (il me semble, sauf erreur de ma part, qu'il n'existe pas d'autre mode de réplication en local. Voir peut-être le système SAN qui utilisait un protocole SCSI)

schema huit

Le système Raid peut-être logiciel ou matériel. S'il est logiciel, c'est la couche applicative ou le système d'exploitation qui effectue cette réplication. S'il est matériel, c'est le système physiquement (contrôleur, carte dédiée, ...) qui effectue la réplication sur les N disques.

La solution logicielle est certes plus économique mais demande plus de ressource processeur que son homologue matériel. De plus, la solution logicielle est gérée par une couche applicative et les logiciels sont plus sujets à des problèmes, notamment les bugs, que les solutions matérielles.

Les solutions matérielles, elles, sont plus fiables mais sont plus onéreuses.

2) La réplication par réseau

Pour notre cas ci-dessus, il existe deux cas pour la réplication : de serveur-services à serveur-services ou bien de serveur-données à serveur-données.

Le premier cas est une réplication par réseau des données essentielles pour les deux serveurs. Ainsi, si le serveur de services primaire est indisponible, le serveur de sauvegarde sera parfaitement operationnel avec l'ensemble des données à sa disposition.

schema neuf

A son retour, la resynchonisation du serveur primaire s'effectuera immédiatement et automatiquement.

Le deuxième cas est une réplication du serveur de partages. Le principe est le même que pour les serveurs de services.

schema dix

La réplication ne se fait qu'au niveau des serveurs de données. Les deux groupements de serveurs sont liés par un "lien" Heartbeat qui assure une reprise par le serveur secondaire si le primaire venait à tomber.

Il existe une autre manière d'obtenir une haute disponibilité à l'aide d'un ensemble de serveurs. Il s'agit d'une méthode utilisant le système SAN/NAS.

III) Les exemples concret de haute disponibilité.

A l'aide des connaissances acquises ci-dessus, nous pouvez établir quelques exemples pour des services de haute disponibilité. Nous décrirons aussi les avantages et les inconvénients de chaque solution.

A. FailOverServices Simples

Nombre de machines minimum nécessaire : 2
Logiciels ou matériels nécessaires : HeartBeat + services multipliés par le nombre de serveurs.


schema quatorze


B. FailOverServices Simples avec réplication locale

Nombre de machines minimum nécessaire : 2
Logiciels ou matériels nécessaires : HeartBeat + Raid + services multipliés par le nombre de serveurs.


schema quinze


C. FailOverServices Simples avec réplication réseau

Nombre de machines minimum nécessaire : 2
Logiciels ou matériels nécessaires : HeartBeat + Système de fichier de réplication + les services multipliés par le nombre de serveurs.


schema quinze b


D. FailOverServices Simples avec utilisation d'un serveur de données

Nombre de machines minimum nécessaire : 3
Logiciels ou matériels nécessaires : heartBeat + NFS (ou équivalent) + les services multipliés par le nombre de serveurs-services.


schema seize


E. FailOverServices Simples avec utilisation d'un serveur de données "FailOveriser" réplication réseau

Nombre de machines minimum nécessaire : 4
Logiciels ou matériels nécessaires : heartBeat + NFS (ou équivalent) + Système de fichiers réplication réseau + les services multipliés par le nombre de serveurs-services.


schema dix-sept


F. FailOverServices Simples avec utilisation d'un serveur de données "FailOveriser" réplication réseau et local

Nombre de machines minimum nécessaire : 4
Logiciels ou matériels nécessaires : heartBeat + NFS (ou équivalent) + Système de fichiers réplication réseau + RAID + les services multipliés par le nombre de serveurs-services.


schema dix-huit


G. FailOverServices avec du LoadBalancing avec utilisation d'un ou plusieurs serveurs de données "FailOveriser" réplication réseau et local

Nombre de machines minium nécessaire : 10 (voire moins si on joue avec l'optimisation machine)
Logiciels ou matériels nécessaires : heartBeat + NFS (ou équivalent) + Système de fichiers + réplication réseau + RAID + Routeur/Switch ou tout autres logiciels qui permet de faire du routage + les services multipliés par le nombre de serveurs-services.


schema dix-neuf


Le mot de la fin

Comme vous l'avez constaté, il existe de nombreuses variantes de haute disponibilité. Je vais donc m'arrêter là car il existe autant de choix de structures réseau que de problèmes. L'infrastructure dépendra de ce que vous voulez en faire et de votre inquiétude pour la disponibilité des données et des services.

Je n'ai pas tout couvert, comme par exemple le NAS/SAN dans les exemples d'infrastructures. Tout simplement parce que les serveurs de données (voir juste au-dessus) peuvent très bien être des serveurs simples (NFS) ou bien des serveurs NAS/SAN.

Il vous suffit juste de modéliser votre réseau comme bon vous semble.

Je vous conseillerais pour autant de réfléchir sur chaque serveur (même le secondaire, du secondaire, du ..etc..) sur le moyen de le faire "tomber". Vous trouverez toujours une solution.

Par contre, ne poussez pas la haute disponibilité à l'extrême jusqu'à concevoir des centaines de réseau dispatchés sur le globe qui disposeraient d'une cinquantaine de machines juste pour être sûr que votre serveur internet ou votre serveur smtp soit disponible à toute heure.


Bonne construction...


(1) Une disponibilité de l'ordre de 100% n'est que théorique. Aucun service ne peut être disponible à 100%. Cependant lorsque l'on parle de haute disponibilité, les services s'approchent de ce chiffre, mais une panne exceptionnelle de tout ordre peut intervenir (Foudre, Feu, Apocalypse...)

(2) La machine de référence est la machine où le service est installé.

(3) Ce lien est un "lien heartbeat", il peut être de toutes formes : cable série, Ethernet, Wireless, Transmission de pensée, etc...

(4) Il est vrai que FOS et Linux Virtual Server peuvent très bien être complémentaires comme pour le cas des serveurs de Load Balacing (voir plus bas dans la section "Linux Virtual Server").

(5) Bien sûr, cela dépend de l'architecture machine, un 486 ne pourra pas être en charge d'autant de serveurs qu'un processeur plus evolué.

(6) Cela peut poser problème pour certains programmes où la sécurité est primordiale chez eux.

(7) NFS est plutôt un cas particulier car il est plus dans l'optique du partage de données.

(8) J'ai repéré quelques systèmes de fichiers spécialement pour le partage comme NFS : ClusterNFS, il me semble que c'est un patch pour le serveur NFS universel ; Network Disk Device.

Appendice A : documentation en français de l' IP Aliasing

Appendix B : une série de liens utiles :


Notes de l'auteur :
Je tiens à remercier Anne qui a pris du temps pour corriger les très nombreuses fautes de l'article original et qui a converti la documentation en HTML.
Je jure que la prochaine fois, je me relirai ;-)

Haut


Routeur FLI4L

par Eric M.C.DECLERCK, version HTML par Anne


C'est quoi Fli4L ?

FLI4L est un routeur Ethernet, ISDN (RNIS), ADSL fondé sur Linux (Debian). Une seule disquette est nécessaire. Et il suffit d'un PC 486 avec 16 Mo de RAM pour créer un routeur. La disquette peut être créée sous Unix, Linux ainsi que sous Windows. Aucune connaissance spécifique à Linux n'est nécessaire mais il est néanmoins utile de maîtriser les commandes de base du système. Et une connaissance de base des réseaux telle que TCP/IP, DNS et routage est également conseillée.

Caractéristiques

Routeur

Support Ethernet

Gestionnaires pour la plupart des cartes réseau : plus de 40 familles de cartes reconnues.

Support ADSL

Support ISDN

Applications en option (packages)

Hardware

Autres informations

Pour l'affichage des informations de contrôle du routeur FLI4L, une autre application est disponible : le client imonc. Ce programme est disponible pour Windows pour Linux (unix/gtk-imonc) et pour Windows

Vous trouverez ici d'autres clients pour KDE, Windows, etc.

Site Web
Auteur du programme : Frank Meyer
Informations en anglais et bien d'autres

Installation

Il est conseillé de commencer par une installation sur disquette. Mais, il est également possible d'installer FLI4L sur un disque dur ou une cartouche Zip. Cette solution (utilisation d'une disquette) est idéale pour tout ceux qui possèdent un second ordinateur déjà relié en réseau via un hub (concentrateur) ou un switch (commutateur).

Je vais ici décrire l'installation que j'ai faite pour un essai de connexion en ISDN. Afin de rendre les choses un peu difficiles j'ai choisi d'utiliser la carte Gazel ISA.

L'équipement de mon réseau :

Procédure

Il faut d'abord s'assurer que les utilitaires isapnp sont installés sur l'ordinateur qui fera fonction de routeur. Faire un pnpdump > isapnp.conf-tmp.

Editer le fichier isapnp.conf-tmp. Enlever toutes les parties qui ne concernent pas la carte Gazel. Ne pas oublier de préciser l'IRQ et l'IO exact de la carte. Pour connaître ces deux paramètres, vous pouvez vous reporter aux informations fournies par le Gestionnaire de périphériques) de Windows (si Windows est installé sur le PC), ou bien lancer un utilitaire de configuration sous MS-Dos livré avec la carte ISDN.

Copier isapnp.conf-tmp sur une disquette (formatée en vfat) en le renommant isapnp.conf. Attention, dans la doc on préconise de le faire après le démarrage du routeur. A éviter, cela ne marche pas ! Il est inutile de faire quoi que ce soit sous le compte root pour FLI4L. Donc, restez sous votre compte utilisateur.

Télécharger fli4l-2.0.4.tar.gz. Télécharger également isdn.tar.gz et gtk-imonc-0.1.6.tar.gz (trop fainéant pour taper les commandes au clavier :)).

Décompacter fli4l-2.0.4.tar.gz dans un sous-répertoire de mon dossier utilisateur. (ex : /~/isdn-routeur).
Décompacter isdn.tar.gz dans le dossier fli4l-2.0.4 (ex : /~/isdn-routeur/fli4l-2.0.4/).
Décompacter gtk-imonc-0.1.6.atr.gz dans un sous dossier de mon dossier utilisateur.
Copier isapnp.conf qui se trouve sur la disquette dans /~/isdn-routeur/fli4l-2.0.4/opt/etc.
Aller dans /~/isdn-router/fli4l-2.0.4.

Configuration FLI4L

Editer /~/isdn-router/fli4l-2.0.4/config/base.txt. L'adapter en fonction de sa configuration et des services que l'on souhaite mettre en place et sauver ensuite le fichier base.txt.

Voici mon fichier de configuration base.txt :

#----------------------------------------------
# General settings:
#----------------------------------------------
# name of fli4l router (ex. fli4l)
HOSTNAME='xxxxxx'               
# password for telnetd, ftpd and sshd (nécessaire)
PASSWORD='xxxxxx'                
# mount boot device (floppy): ro, rw, no
MOUNT_BOOT='rw'                 

# size of ramdisk for unzipped opt.tgz
RAMSIZE='2048'                  
# the variables MOUNT_OPT, PART_OPT and UPDATE_MODE 
# will be ignored if # RAMSIZE is not empty. see  docu
# mount opt device: ro, rw
MOUNT_OPT='ro'                  
# location of opt-files, ram1 or disk-partition
PART_OPT='ram1'                 
# add, cfg, full, none, see documentation
UPDATE_MODE='full'              

#----------------------------------------------
# Ethernet card drivers:
# uncomment your ethernet card
#----------------------------------------------
# number of ethernet drivers to load, usually 1
ETH_DRV_N='1'                   
# ISA: 3COM Etherlink Plus (3c505)
#ETH_DRV_1='3c505'              
# ISA: 3COM Etherlink 16 (3c507)
#ETH_DRV_1='3c507'              
# ISA: 3COM EtherLinkIII (3c509)
#ETH_DRV_1='3c509'              
# ISA: 3COM EtherLink XL ISa (3c515)
#ETH_DRV_1='3c515'              
# PCI: 3COM Vortex/Boomerang 3c59x,3c900,3c905
#ETH_DRV_1='3c59x'              
# Apricot Xen-II on board Ethernet
#ETH_DRV_1='82596'              
# ISA: 3COM EtherLinkII (3c503)
#ETH_DRV_1='3c503'              
# ISA: Cabletron E21xx ISA
#ETH_DRV_1='e2100'              
# ISA: HP PCLAN (27245, 27xxx) ISA
#ETH_DRV_1='hp'                 
# ISA: HP PCLAN+ (27247B and 27252A) ISA
#ETH_DRV_1='hp-plus'            
# ISA: NE2000 ISA clone (eg. Realtek 8019,
# Accton 16xx, NatSemi 8390, UMC 9003/9008)
#ETH_DRV_1='ne'                  
# PCI: NE2000 PCI clone (eg. Realtek 8029,    
# Winbond 89c940)                                           
#ETH_DRV_1='ne2k-pci'           
# ISA: SMC ULTRA                                              
#ETH_DRV_1='smc-ultra'          
# EISA: SMC ULTRA32 (NEW)
#ETH_DRV_1='smc-ultra32'        
# ISA: SMC WD80*3
#ETH_DRV_1='wd'                 
# ISA: AT1700 (Fujitsu 86965) ISA
#ETH_DRV_1='at1700'             
# ISA: IBM Etherjet, cs89x0 based Cards (Option io=0xnnn necessary!)
#ETH_DRV_1='cs89x0'             
# PCI/EISA: Digital DE425, DE434, DE435, DE450, DE500
#ETH_DRV_1='de4x5'              
# ISA: DEPCA, DE10x, DE200, DE201, DE202, DE422
#ETH_DRV_1='depca'              
# PCI: Digi International RightSwitch PCI/EISA
#ETH_DRV_1='dgrs'               
# PCI: DM9102 compatible PCI cards from Davicom
#ETH_DRV_1='dmfe'               
# ISA: Intel Professional Workstation/panther 82596
#ETH_DRV_1='elp486'             
# ISA: Intel EtherExpress Pro/10
#ETH_DRV_1='eepro'              
# PCI: Intel EtherExpressPro PCI 10+/100B/100+
#ETH_DRV_1='eepro100'           
# ISA: EtherExpress16 ISA
#ETH_DRV_1='eexpress'           
# PCI: SMC EPIC/100 (EtherPower II) PCI
#ETH_DRV_1='epic100'            
# ISA/EISA: ICL EtherTeam 16i/32
#ETH_DRV_1='eth16i'             
# ISA: EtherWORKS 3 ISA (DE203, DE204, DE205)
#ETH_DRV_1='ewrk3'              
# PCI: ASOUND LAN 8139 card - not RTL8139 (NEW)
#ETH_DRV_1='fealnx'             
# ISA/EISA/PCI: HP 10/100VG PCLAN (ISA, EISA, PCI)
#ETH_DRV_1='hp100'              
# ISA: AMD LANCE and PCnet (AT1500, NE2100) ISA
#ETH_DRV_1='lance'              
# PCI: Old DECchip Tulip (dc21x4x) PCI
#ETH_DRV_1='old_tulip'          
# PCI: AMD PCI PCnet32
#ETH_DRV_1='pcnet32'            
# PCI: RealTek 8129/8139 (not 8019/8029!)
#ETH_DRV_1='rtl8139-orig'       
# PCI: RealTek 8129/8139 (not 8019/8029!) (NEW)
#ETH_DRV_1='rtl8139'            
# PCI: RealTek 8139 10/100 MB (NEW)
#ETH_DRV_1='8139too'            
# PCI: SiS 900/7016
#ETH_DRV_1='sis900'             
# PCI: DFE-550FX or DFE-530TXS (NEW)
#ETH_DRV_1='sundance'           
# PCI: TI ThunderLAN (Compaq Netelligent ...)
#ETH_DRV_1='tlan'               
# PCI: DECchip Tulip (dc21x4x) PCI
#ETH_DRV_1='tulip'              
# PCI: Nat Semi
#ETH_DRV_1='natsemi'            
# PCI: Starfire
#ETH_DRV_1='starfire'          
# PCI: VIA Rhine PCI (3043, VT86c100A, dfe-530tx) 
ETH_DRV_1='via-rhine'          
# PCI: Winbond 840
#ETH_DRV_1='winbond-840'        
# Token Ring: IBM Auto LANStreamer PCI Adapter
#ETH_DRV_1='lanstreamer'        
# Token Ring: IBM cards (Pit/Pit-Phy/Olympic)
#ETH_DRV_1='olympic'            
# Token Ring: IBM 16/4
#ETH_DRV_1='ibmtr'              
# PCMCIA: NS8390-based cards (NE2000, DLINK etc)
#ETH_DRV_1='pcnet_cs'           
# PCMCIA: 3Com 574
#ETH_DRV_1='3c574_cs'           
# PCMCIA: 3Com 575
#ETH_DRV_1='3c575_cb'           
# PCMCIA: 3Com 589
#ETH_DRV_1='3c589_cs'           
# PCMCIA: Airo 4500 & 4800 series cards
#ETH_DRV_1='airo'               
# PCMCIA: Airo 4500 & 4800 series cards
#ETH_DRV_1='airo_cs'            
# PCMCIA: EtherExpress Pro 100
#ETH_DRV_1='eepro100_cb'        
# PCMCIA: SMC 83c170 EPIC/100
#ETH_DRV_1='epic_cb'            
# PCMCIA: IBM Token Ring
#ETH_DRV_1='ibmtr_cs'           
# PCMCIA: Netwave AirSurfer Wireless LAN
#ETH_DRV_1='netwave_cs'         
# PCMCIA: New Media Ethernet LAN
#ETH_DRV_1='nmclan_cs'          
# PCMCIA: Raylink wireless cards
#ETH_DRV_1='ray_cs'             
# PCMCIA: SMC91c92-based cards
#ETH_DRV_1='smc91c92_cs'        
# PCMCIA: DEC 21040-family cards
#ETH_DRV_1='tulip_cb'           
# PCMCIA: WaveLAN
#ETH_DRV_1='wavelan_cs'         
# PCMCIA: WaveLAN2
#ETH_DRV_1='wavelan2_cs'        
# PCMCIA: Lucent WaveLAN/IEEE 802.11
#ETH_DRV_1='wvlan_cs'           
# PCMCIA: Xircom: CE2, CEM28, CEM33, or CE3
#ETH_DRV_1='xirc2ps_cs'         
# PCMCIA: ELSA Airlancer MC-2
#ETH_DRV_1='wl24_cs'            
# PCMCIA: IBM EtherJet Ethernet Adapter
#ETH_DRV_1='cs89x0_cs'          
# additional option, e.g. 'io=0x340' for ne
ETH_DRV_1_OPTION=''             

#----------------------------------------------
# Ether networks used with IP protocol:
#----------------------------------------------
# number of ip ethernet networks, usually 1
IP_ETH_N='1'                        
# optional: other device name than ethX
IP_ETH_1_NAME=''                    
# IP address of your n'th ethernet card
IP_ETH_1_IPADDR='192.168.12.1'       
# network of your LAN
IP_ETH_1_NETWORK='192.168.12.0'     
# netmask of your LAN 
IP_ETH_1_NETMASK='255.255.255.0'    

#----------------------------------------------
# Additional routes, optional
#----------------------------------------------
# normally not used, read documentation!
IP_DEFAULT_GATEWAY=''               
# number of additional routes
IP_ROUTE_N='0'                      
# network netmask gateway
#IP_ROUTE_1='192.168.7.0 255.255.255.0 192.168.6.99' 

#----------------------------------------------
# Masquerading:
#----------------------------------------------
# networks to masquerade (e.g. our LAN)
MASQ_NETWORK='192.168.12.0/24'       
# load n masq modules (default: only ftp)
MASQ_MODULE_N='1'                   
# ftp
MASQ_MODULE_1='ftp'                 
# h323 (netmeeting)
#MASQ_MODULE_2='h323'                
# icq (use with caution!)
#MASQ_MODULE_3='icq'                 
# irc
#MASQ_MODULE_4='irc'                 
# raudio
#MASQ_MODULE_5='raudio'              
# vdolive
#MASQ_MODULE_6='vdolive'             
# quake
#MASQ_MODULE_7='quake'               
# cuseeme
#MASQ_MODULE_8='cuseeme'             
# MSN-Filetransfer
#MASQ_MODULE_9='mms'                 
# pptp
#MASQ_MODULE_10='pptp'               
# ipsec
#MASQ_MODULE_11='ipsec'              
# dplay (direct play)
#MASQ_MODULE_12='dplay'              
# msn zone (use version 0.01 or 0.02)
#MASQ_MODULE_13='msn-0.02'           
# pseudo mod: some internet games need it
#MASQ_MODULE_14='udp_dloose'         
# using ftp masq-module on different ports
MASQ_FTP_PORT_N='0'                 
# standard ftp port
#MASQ_FTP_PORT_1='21'           
# additional port (le cas de free.fr mais marche aussi sans)     
#MASQ_FTP_PORT_2='2021'         

#----------------------------------------------
# Optional package: PORTFW
#
# If you set OPT_PORTFW='yes', you can also edit
# opt/etc/portfw.sh
#----------------------------------------------
# install port forwarding tools/modules
OPT_PORTFW='no'                     
# how many portforwardings to set up
PORTFW_N='0'                        
# sample 1: forward ext. port 8080 to int.
# host 192.168.6.15 to port 80 (use tcp)
#PORTFW_1='8080 192.168.6.15:80 tcp' 
                                    
# sample 2: forward portrange to int. host
# 192.168.5.15 (use tcp)
#PORTFW_2='3000-3010 192.168.6.15 tcp' 
                                    


#----------------------------------------------
# Routing without masquerading
#----------------------------------------------
# optional: route from/to network, no masq
ROUTE_NETWORK=''                    

#----------------------------------------------
# Routing: internal hosts to deny forwarding
#----------------------------------------------
# number of denied hosts
FORWARD_DENY_HOST_N='0'             
# optional: 1st denied host
#FORWARD_DENY_HOST_1='192.168.6.5'   
# optional: 2nd denied host
#FORWARD_DENY_HOST_2='192.168.6.6'   

#----------------------------------------------
# Routing: ports to reject/deny forwarding (from 
# inside and outside!)
#----------------------------------------------
# no. of ports to reject/deny forwarding
FORWARD_DENY_PORT_N='1'                 
# deny/reject forwarding of netbios
FORWARD_DENY_PORT_1='137:139    REJECT' 
# but allow forwarding between LANs
FORWARD_TRUSTED_NETS=''                 

#----------------------------------------------
# Firewall: ports to reject/deny from outside 
# (all served ports)
#
# here we leave two ports untouched:
#
#  53 dns
# 113 auth
#----------------------------------------------
# no. of ports to reject/deny
FIREWALL_DENY_PORT_N='6'                
# privileged ports: reject or deny
FIREWALL_DENY_PORT_1='0:52      REJECT' 
# privileged ports: reject or deny
FIREWALL_DENY_PORT_2='54:112    REJECT' 
# privileged ports: reject or deny
FIREWALL_DENY_PORT_3='114:1023  REJECT' 
# imond/telmond ports: reject or deny
FIREWALL_DENY_PORT_4='5000:5001 REJECT' 
# proxy access: reject or deny
FIREWALL_DENY_PORT_5='8000      REJECT' 
# vbox server access: reject or deny
FIREWALL_DENY_PORT_6='20012     REJECT' 
# deny icmp (ping): yes or no
FIREWALL_DENY_ICMP='no'                 
# log access to rejected/denied ports
FIREWALL_LOG='yes'                      

#----------------------------------------------
# Domain configuration:
#----------------------------------------------
# start dns server: yes or no
START_DNS='yes'                   
# DNS servers of your provider, e.g. MSN (free.fr)  
DNS_FORWARDERS='212.27.32.5'      
# log queries in /usr/local/ens/ens.log
DNS_VERBOSE='no'                    
# your domain name
DOMAIN_name="lfli4l.php3_mydomain.dd"           
# number of forbidden domains  
DNS_FORBIDDEN_N='0'                 
# 1st forbidden domain
#DNS_FORBIDDEN_1='foo.bar'           
# 2nd forbidden domain
#DNS_FORBIDDEN_2='bar.foo'          
# number of hosts in your domain 
HOSTS_N='3'                         
# 1st host: ip and name, choice is yours
HOST_1='192.168.12.1 fli4l'          
# 2nd host: ip and name
HOST_2='192.168.12.2 client2'        
# 3rd host: ip and name
HOST_3='192.168.12.3 client3'        
# 4th host: ip and name
#HOST_4='192.168.12.4 client4'        

#----------------------------------------------
# Special DNS configuration
#----------------------------------------------
# number of special dns servers, normally 0
DNS_N='0'                           
# 1st special dns server for firma.de
#DNS_1='firma.de 192.168.1.12'      
# 2nd special dns server for lan.firma.de
#DNS_2='lan.firma.de 192.168.2.12'  

#----------------------------------------------
# imond configuration:
#----------------------------------------------
# start imond: yes or no
START_IMOND='yes'                   
# TCP-Port, see also FIREWALL_DENY_PORT_x! 
IMOND_PORT='5000'                   
# imond-password, may be empty
IMOND_PASS='zzzzz'                       
# imond-admin-password, may be empty
IMOND_ADMIN_PASS='yyyyyyyyy'        
# tty for led: com1 - com4 or empty         
IMOND_LED=''                        
# beep if connexion going up/down
IMOND_BEEP='yes'                    
# log /var/log/imond.log: yes or no 
IMOND_LOG='no'                   
# log-directory, e.g. /var/log   
IMOND_LOGDIR='/boot'             
# accept "enable/disable" commands
IMOND_ENABLE='yes'                  
# accept "dial/hangup" commands
IMOND_DIAL='yes'                    
# accept "route" command
IMOND_ROUTE='yes'                   
# accept "reboot" command
IMOND_REBOOT='yes'                  

#----------------------------------------------
# Generic circuit configuration:
#----------------------------------------------
# use dyn. ip addresses (most providers do)(nécessaire
# pour l'ISDN)
IP_DYN_ADDR='yes'            
# standard dialmode: auto, manual, or off
DIALMODE='manual'                     

#----------------------------------------------
# optional package: syslogd
#----------------------------------------------
# start syslogd: yes or no
OPT_SYSLOGD='no'                    
# number of destinations
SYSLOGD_DEST_N='1'                  
# n'th prio & destination of syslog msgs
SYSLOGD_DEST_1='*.* /dev/console'   
# example: loghost 192.168.6.2
SYSLOGD_DEST_2='*.* @192.168.6.2'   
# example: log infos
SYSLOGD_DEST_3='kern.info /var/log/dial.log'    

#----------------------------------------------
# optional package: klogd
#----------------------------------------------
# start klogd: yes or no
OPT_KLOGD='no'                      

#----------------------------------------------
# optional package: y2k correction
#----------------------------------------------
# y2k correction: yes or no
OPT_Y2K='no'                        
# correct hardware Y2K-Bug: add x days
Y2K_DAYS=''                         

#----------------------------------------------
# Optional package: PNP
#----------------------------------------------
# install isapnp tools: yes or no
OPT_PNP='yes'                        

Configuration ISDN

Aller dans /~/isdn-routeur/fli4l-2.0.4/config. Editer le fichier isdn.txt. L'adapter à sa configuration et l'enregistrer.

Voici ma configuration pour la carte Gazel :

#----------------------------------------------
# Optional package: ISDN
#----------------------------------------------
# use ISDN: yes or no
OPT_ISDN='yes'                       
# type, e.g. Gazel ISA. Voir liste
ISDN_TYPE='34'                      
# io, e.g. 0x240 for Gazel ISA. Voir isapnp.conf !!! 
ISDN_IO='0x240'                     
# io0
ISDN_IO0=''                         
# io1
ISDN_IO1=''                         
# mem
ISDN_MEM=''                         
# irq, e.g. 12 for Gazel ISa (mon cas)
ISDN_IRQ='12'                       
# debug level (hisax driver)
ISDN_DEBUG_LEVEL='31'               
# verbose level
ISDN_VERBOSE_LEVEL='2'              

#----------------------------------------------
# ISDN compression (EXPERIMENTAL):
#----------------------------------------------
# use LZS or BSD compression: 'yes' or 'no'
OPT_ISDN_COMP='no'                  
# debug level lzscomp (0..3)
ISDN_LZS_DEBUG='1'                  
# compression level lzscomp (0..9)
ISDN_LZS_COMP='8'                   
# tweak lzscompr (at present: 0..7)
ISDN_LZS_TWEAK='7'                  

#----------------------------------------------
# ISDN Circuits:
#----------------------------------------------
# no. of ISDN circuits, DSL: see pppoe.txt
ISDN_CIRCUITS_N='1'                 

#----------------------------------------------
# Circuit 1: Internet-By-Call-Provider MSN
#----------------------------------------------
# circuit MSN
ISDN_CIRC_1_name="lfli4l.php3_mydomain.dd"      
# use dns server of your provider: yes or no       
ISDN_CIRC_1_USEPEERDNS='no'         
# circuit uses sync ppp (ipppd)
ISDN_CIRC_1_TYPE='ppp'              
# channel bundling: yes or no
ISDN_CIRC_1_BUNDLING='no'           
# if bundling=yes: opt. bandwidth on demand
ISDN_CIRC_1_BANDWIDTH=''            
# local ip address of your ISDN card - dummy
ISDN_CIRC_1_LOCAL=''                
# remote ip address (ISDN) - dummy
ISDN_CIRC_1_REMOTE=''               
# netmask (ISDN) - dummy
ISDN_CIRC_1_NETMASK='255.255.255.0' 
# max transmission unit (use 1500 if comp!)
ISDN_CIRC_1_MTU='1500'              
# maximum receive unit
ISDN_CIRC_1_MRU='1524'              
# compress headers/frames, see docum.
ISDN_CIRC_1_COMPRESSION='no'        
# type of framecompression, see docum.
ISDN_CIRC_1_FRAMECOMP='default'     
# optional: ipx network
ISDN_CIRC_1_IPX_NETWORK=''          
# optional: ipx nodes local:remote
ISDN_CIRC_1_IPX_NODE=''             
# optional: remote hostname for dialin
ISDN_CIRC_1_REMOTENAME='aaaaa;bbb'          
# User-ID to login into provider's gateway 
ISDN_CIRC_1_USER='my.id.login'              
# Password for login
ISDN_CIRC_1_PASS='my-password'              
# this is the default route
ISDN_CIRC_1_ROUTE='0.0.0.0'         
# dialout: ISDN number of provider
ISDN_CIRC_1_DIALOUT='0860922000'    
# dialin: no dialin   
ISDN_CIRC_1_DIALIN=''               
# callback mode: 'in', 'out', or 'off'
ISDN_CIRC_1_CALLBACK='off'          
# callback delay, only used for callbacks
ISDN_CIRC_1_CBDELAY='3'            
# your MSN (without area code) 
ISDN_CIRC_1_EAZ='5255'             
# optional slave MSN for channel bundling
ISDN_CIRC_1_SLAVE_EAZ=''            
# enable ipppd debugging, 'yes' or 'no'
ISDN_CIRC_1_DEBUG='yes'             
# require the peer to authenticate itself
ISDN_CIRC_1_AUTH=''                 
# Hangup after 175 seconds idle time
ISDN_CIRC_1_HUP_TIMEOUT='175'        
# Value of charge interval (in seconds)
ISDN_CIRC_1_CHARGEINT='180'           
# times/charges when LCR
ISDN_CIRC_1_TIMES='Mo-Su:00-24:0.0148:Y'        

#----------------------------------------------
# Circuit 2: bidirectional connexion to another 
# router with raw tcpip not activated yet, only
# example for non-default-circuit
#----------------------------------------------

#----------------------------------------------
# telmond configuration:
#----------------------------------------------
# start telmond: yes or no
OPT_TELMOND='yes'               
# TCP-Port, see also FIREWALL_DENY_PORT_x! 
TELMOND_PORT='5001'             
# log /var/log/telmond.log: yes or no
TELMOND_LOG='no'                
# log-directory, e.g. /var/log
TELMOND_LOGDIR='/var/log'       
# number of msn->ip mapping entries
TELMOND_MSN_N='0'               
# e.g. map MSN 123 to client 192.168.6.2
TELMOND_MSN_1='123 192.168.6.2' 
# no. of commands to be executed if call-in
TELMOND_CMD_N='0'               
# e.g. dial out via default circuit
TELMOND_CMD_1='123 * sleep 5; imonc dial'  

Construction de la disquette

Aller dans /~/isdn-routeur/fli4l-2.0.4 et introduire une disquette vierge dans le lecteur.
Formater la disquette : fdfomat /dev/fd0u1680 (de préférence, choisissez une disquette de bonne qualité pour utiliser ce format).
Pour plus de sécurité : ./mkclean.sh
Compresser les fichiers nécessaires : ./mktgz.sh
Copier les fichiers sur la disquette : ./mkfloppy.sh -h (le paramètre -h est nécessaire pour les disquette de 1680 ko)

Interface de numérotation

Puisque j'ai choisi une numérotation manuelle sous X-Window, construisons le programme gtk-imonc ! Remarque : pour les mordus du clavier, vous pouvez utiliser une application en console : imonc, à télécharger sur le site de fli4l.de).

Aller dans /~/gtk-imonc-0.1.6
Exécuter ./configure
Exécuter ./make
Exécuter su afin de basculer sous le compte root
Exécuter ./make install afin d'installer le programme gtk-imonc dans /usr/local/bin.

Vous pouvez par la suite repérer le fichier gtk-imoc.desktop et le copier ou le glisser à la souris vers le Bureau.

Voilà ! C'est aussi simple que cela.

La configuration réseau

Ne pas oublier si ce n'est pas déjà fait, de saisir les commandes suivantes (en root) :

ifconfig eth0 192.168.12.x netmask 255.255.255.0 up
route add default gw 192.168.12.1 eth0

Pour autant que votre réseau est le 192.168.12.0 !!

Elles réinitialisent la carte réseau avec l'adresse IP correspondante au réseau sur lequel le routeur ISDN officie et ajustent la passerelle par défaut. Remplacez 192.168.12.x par l'adresse IP du poste de travail.

La minute de vérité !

Introduisons la disquette dans l'ordinateur qui doit fonctionner en tant que routeur et mettons-le en route.

...syslinux.....
...kernel........

Messages d'erreur ??? Impossible ;-)

Login :
Saisissez votre login, puis votre mot de passe
ATTENTION, le clavier est en qwerty-US. Choisissez donc un mot de passe qui reste facile à mémoriser et qui ne fait pas appel aux lettres A, Q, Z, W et M.

De retour à votre poste de travail, lancez gtk-imonc. Cliquez sur le bouton DIAL. Un témoin de connexion s'affiche dans le bas de la fenêtre.

Have fun !

Le mot de la fin

Toute la documentation officielle est dans le répertoire fli4l-2.0.4, malheureusement en Allemand. Une liste de diffusion existe mais uniquement en Allemand !

Je conseille de faire une deuxième disquette et, dans le fichier base.txt, d'ajouter le paramètre : (pour le cas où :))

MOUNT_BOOT='ro'                 # mount boot device (floppy): ro, rw, no

A voir ici : une 'one-floppy' passerelle construite par Torben Baras. Il l'a nommé 'Silent Router'. Devinez pourquoi ;-)


Construit à partir d'une carte mère 486-DX2 Intel 66 Mhz CPU dans un rack de 19" et fli4l.

Haut


Le LVM (Logical Volume Manager)

Par Anne

Un des aspects cruciaux dans l'administration d'un serveur ou d'une machine de bureau est la gestion de l'espace disque. Quoi de plus énervant que de voir l'installation d'une application échouer par manque d'espace, ou un serveur rendu indisponible parce que le système de fichiers /var était plein du fait des fichiers de log ?

Un outil apporte une solution satisfaisante et efficace : le LVM (Logical Volume Manager).

De l'utilité du LVM

Le LVM ou Logical Volume Manager, est une technique créée à la base par IBM consistant à fournir la possibilité de modifier la taille des partitions sur les disques durs sans avoir besoin de tout reformater, voire de créer des partitions s'étalant sur plusieurs disques. L'objectif est ainsi d'éviter arret et redemarrage d'une machine en production. Cette technique est disponible sur linux depuis la version 2.4 du noyau (très exactement 2.3.47).

Dans un partitionnement de type classique, à l'aide des commandes fdisk, vous ne pouvez avoir que 4 partitions primaires pour chaque disque (en IDE) ou éventuellement 3 partitions primaires et une partition étendue qui contiendra des partitions logiques. L'inconvénient de ce type de partitionnement est que lorsque vous souhaitez réduire la taille d'une partition ou l'augmenter, vous devez notamment disposer d'outils spécifiques comme GNU-parted. De plus, le partitionnement ne se fera que disque par disque. Imaginez alors que vous souhaitiez ajouter un deuxième disque sur votre machine ou agrandir la taille de votre système de fichiers /home....

Vous ne pourrez pas profiter de l'espace disponible sur ce deuxième disque pour agrandir /home, à moins d'y accrocher un nouveau système de fichiers. Agacant non ?

Eh bien, LVM est là pour vous simplifier la vie.

Les composants du LVM

Le principe de fonctionnement de LVM est relativement simple. Il s'agit en fait pour effectuer ce type de partitionnement, de s'affranchir complètement des limites physiques du ou des disques disponibles. Les étapes ci-dessous en décrivent le fonctionnement. Le LVM s'accompagne aussi d'un certain nombre de termes techniques énoncés également ci-dessous.

Voici de manière shématique à quoi pourrait ressembler votre(vos) disque(s) après ce traitement (Schéma 2).

Schéma 2 : impact de LVM sur les disques durs

Dans ce cas de figure, les deux disques hda et hdb ont été transformés en volumes physiques. Puis ils ont été insérés tous les deux dans un groupe de volumes appelé vg01. A partir de ce moment-là, il n'est plus nécessaire de tenir compte des limites physiques des disques, en effet, nous n'avons plus qu'un espace, et un seul, de 36 GB (regroupant donc nos deux unités de disques hda et hdb). Le groupe de volumes a ensuite été découpé en 3 volumes logiques, nommées lvol01, lvol02, lvol03. On remarquera que lvol02 est composé de logical extents pointant sur des physical extents appartenant à hda et hdb. La dernière étape consistera à créer un système de fichiers dans chacun de ces volumes logiques.

Remarques :

Utiliser le LVM : ce dont il faut disposer

Pour être utilisé, le LVM nécessite de disposer du driver qui permet de générer la couche assurant le mapping ( la carte) entre périphérique physique et vue logique, des utilitaires pour manipuler ce mapping et des périphériques physiques.

Kernel et utilitaires

Le LVM, dans les distributions récentes (kernel 2.4), est fourni lors de l'installation. Il faut quand même savoir que l'implémentation du LVM se fait à deux niveaux :

Au niveau du kernel lors de l'installation ou de la recompilation du noyau, vous devez avoir intégré ou mis en module le driver LVM. Celui-ci se situe dans le menu de compilation "Multi-device support". On peut le vérifier de la manière suivante :

root@pingu# grep -i lvm /boot/config
# Multi-device support (RAID and LVM)
CONFIG_BLK_DEV_LVM=m

Vous devez également disposer des commandes nécessaires à l'administration du LVM. Elles sont incluses dans le package lvm. Pour vérifier qu'il est installé (dans le cas d'une Mandrake) :

root@pingu# rpm -qa|grep lvm
lvm-1.0.3-9

Toutes les commandes passées en revue dans la suite de cet article font partie de ce paquetage.

Sur quels périphériques et systèmes de fichiers puis-je faire du LVM ?

Pour pouvoir utiliser le LVM, vous devez disposer soit d'un disque vierge (rappel : la création d'un volume physique entrainera la perte de données existantes) et/ou d'une partition primaire vierge (moins utile mais faisable).

Toutefois attention : vous ne pourrez pas mélanger partitionnement classique et LVM au sein d'un groupe de volumes.

Il est possible d'utiliser le LVM pour tous vos systèmes de fichiers, exception faite de « /boot », qui pose quelques problèmes. Par contre il est tout à fait possible de l'inclure sur un ou plusieurs volumes logiques. D'ailleurs la plupart des distributions proposent aujourd'hui cette option dè l'installation. La seule contrainte est de prévoir le chargement du module LVM dès le démarrage. Pour ce faire, on créera une image initrd contenant le module LVM à l'aide de la commande lvmcreate_initrd. On modifiera également en conséquence le fichier /etc/lilo.conf.

Configuration du LVM

Passons maintenant à la pratique.

Pour la mise en application, nous allons reprendre les 3 étapes énoncées ci-dessus. A chaque fois, je présenterai la commande correspondante à la création de l'élément et une commande de recueil d'informations pour vérifier que l'opération a été correctement réalisée.

L'arborescence du LVM

A chaque élément du LVM correspond un fichier spécial dans /dev. Le volume physique est représenté par le fichier spécial du disque dur ou de la partition correspondant. Le groupe de volume dispose d'un répertoire portant son nom dans lequel on trouvera le fichier spécial group.

# ls -l /dev/datas/group
crw-r----- 1 root root 109, 1 jan 1 1970 group

Dans ce répertoire, on trouvera également un fichier spécial par volume logique créé à l'intérieur de ce groupe de volumes.

# tree /dev/users /dev/public
/dev/users
|--datas
|--group
`--private
/dev/public
|--ftp
|--group
`--web

Outre les fichiers spéciaux, on trouve également le fichier /etc/lvmtab et /etc/lvmtab.d. Ils contiennent la base de données manipulée par les commandes lvm.

Création d'un volume physique

La première étape consiste à transformer notre disque en volume physique. L'opération s'effectue en 3 temps :

  1. Préparation de l'espace à utiliser avec le LVM : cette étape s'effectue grâce à la commande fdisk. Vous allez devoir attribuer le type lvm à votre disque ou votre partition :

    root@pingu# fdisk /dev/hdb
    Commande (m pour aide) : p
    Disk /dev/hdb: 13.5 GB, 13578485760 bytes
    255 heads, 63 sectors/track, 1650 cylinders
    Units = cylindres of 16065 * 512 = 8225280 bytes
    
    Périphérique Amorce    Début       Fin    Blocs   Id  Système
    /dev/hdb1            1       730   5863693+  8e  Linux LVM
    /dev/hdb2          731      1339   4891792+  8e  Linux LVM
    /dev/hdb3         1340      1650   2498107+  8e  Linux LVM

  2. Ensuite, il est nécessaire de lancer la commande vgscan si vous utilisez LVM pour la première fois sur le disque dur ou la partition. La commande va créer notamment le fichier /etc/lvmtab et le répertoire /etc/lvmtab.d.

    # vgscan
    vgscan -- reading all physical volumes (this may take a while...)
    vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
    vgscan -- WARNING: This program does not do a VGDA backup of your volume group

  3. Création du volume physique : la commande est pvcreate (physical volume creation).

    pvcreate [-f] </dev/hdxx> où
    -f : force la création du volume. A utiliser si le disque avait déjà été transformé en volume physique.
    /dev/hdxx : fichier spécial du disque ou de la partition à transformer en volume physique

    Exemple : création d'un volume physique à partir de hdb1

    # pvcreate /dev/hdb1
    pvcreate -- physical volume "/dev/hdb1" successfully created

Création d'un groupe de volume

Une fois le volume physique créé, il faut alors insérer le ou les volumes physiques ainsi créés dans un groupe de volumes. On utilise la commande vgcreate :

vgcreate <nom_du_volume></dev/hdxx> où
<nom_du_volume> : nom du groupe de volume - l'opération crée alors le répertoire /dev/nom_du_volume contenant le fichier spécial group qui représente ce groupe de volumes.
</dev/hdxx> : fichier spécial du volume physique

Exemple : création d'un groupe de volumes nommé volume1 avec hdb1

# vgcreate volume1 /dev/hdb1
vgcreate -- INFO: using default physical extent size 4 MB
vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
vgcreate -- doing automatic backup of volume group "volume1"
vgcreate -- volume group "volume1" successfully created and activated

Création d'un volume logique

Une fois le groupe de volume créé, on peut alors le découper en un ou plusieurs volumes logiques grâce à la commande lvcreate :

lvcreate -L tailleK|M|G [-n nom] <nom_volume> où
-L tailleK|M|G : taille du volume logique exprimable en Ko, Mo ou Go
-n nom : nom du volume logique - l'opération crée un fichier spécial portant ce nom pour le volume logique et sera placé dans le répertoire /dev/nom_volume

<nom_volume> : nom du groupe de volumes dans lequel sera créé le volume logique.

Exemple : création d'un volume logique de 600 Mo nommé part1 dans le groupe de volume volume1

# lvcreate -L 600 -n part1 volume1
lvcreate -- doing automatic backup of "volume1"
lvcreate -- logical volume "/dev/volume1/part1" successfully created

Une particularité de la création d'un volume logique est le choix du mapping entre les LE et les PE. Par défaut, ce mapping est effectué de manière linéaire. Il est possible également de réaliser du stripping(répartition des données sur un ou plusieurs diques), ce qui permet d'améliorer le temps d'accè aux données. Ci-dessous, ce schéma montre la différence de répartition des LE en fonction de ces 2 modes.

Des options de la commande lvcreate permettent de donner le nombre de stripes (et donc de volumes physiques utilisés) et leur taille. (Schémas 4 et 5)

Schéma 4 : Volume logique en mode linéaire

Schéma 5 : Volume logique en mode stripping

Recueillir des informations sur le LVM

A tout moment il est possible de recueillir des informations sur les structures LVM : volume physique, groupe de volumes et volumes logiques. On utilisera pour cela respectivement les commandes pvdisplay, vgdisplay et lvdisplay. Ces commandes ne font en fait qu'afficher dans un format lisible le contenu respectif de la PVRA, VGRA. Nous allons détailler les principales informations au moyen d'exemples ci-dessous.

La description d'un volume physique procure notamment le nom du volume physique, le nom du groupe de volume dans lequel est inséré le dit volume physique, sa taille, le nombre de volumes logiques contenus, la taille des physical extents, le nombre de PE contenus dans le volume physique, le nombre de PE libres.

# pvdisplay /dev/hdb1
--- Physical volume ---
PV Name               /dev/hdb1
VG Name               volume1
PV Size               5.59 GB [11727387 secs] /
  NOT usable 4.19 MB [LVM: 133 KB]
PV#                   1
PV Status             available
Allocatable           yes
Cur LV                1
PE Size (KByte)       4096
Total PE              1430
Free PE               1230
Allocated PE          200
PV UUID               DTWrWh-5oUP-KrdB-US55-c9wP-eKii-6z3uU7

La description d'un groupe de volumes permet de vérifier son nom, le type d'accè aux données (écriture, lecture), nombre maximum de volumes logiques créables dans ce groupe de volume, sa taille en PE et LE, ...

# vgdisplay volume1
--- Volume group ---
VG Name               volume1
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                1
Act PV                1
VG Size               5.59 GB
PE Size               4 MB
Total PE              1430
Alloc PE / Size       150 / 600 MB
Free  PE / Size       1280 / 5 GB
VG UUID               5XxOO1-ZNl8-zocw-6dR5-44LX-oyYc-MYHpN2

Enfin la description d'un volume logique contient son nom, le type d'accès aux données, sa taille...

# lvdisplay /dev/volume1/part1
--- Logical volume ---
LV Name                /dev/volume1/part1
VG Name                volume1
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 0
LV Size                600 MB
Current LE             150
Allocated LE           150
Allocation             next free
Read ahead sectors     1024
Block device           58:0

Commandes complémentaires

Jusqu'à maintenant, nous avons vu comment créer des strutures LVM et obtenir de l'information. Nous allons voir maintenant d'autres opérations réalisables pour la gestion du partitionnemement et qui mettent en évidence toute la souplesse apportée par le LVM en la matière : agrandir ou réduire un groupe de volume, redimensionner un volume logique.

Redimensionner un groupe de volumes

Un groupe de volumes est constitué d'un ou plusieurs volumes physiques. Il est possible à tout moment d'ajouter ou retirer un ou plusieurs volumes physiques afin d'augmenter ou diminuer l'espace disponible d'un groupe de volumes.

Les commandes sont respectivement vgextend et vgreduce :

vgextend nom_volume /dev/hdxx
vgreduce nom_volume /dev/hdxx

nom_volume : nom du groupe de volume à redimensionner
/dev/hdxx : volume physique à ajouter ou retirer du groupe de volumes

Vous devez augmenter l'espace du groupe de volume volume1 de 6 Go. Pour cela vous disposez d'un disque que vous allez ajouter. Ci-dessous les étapes à réaliser :

  1. création du volume physique à partir de hdb2

    # pvcreate /dev/hdb1
    pvcreate -- physical volume "/dev/hdb1" successfully created

  2. ajout de hdb2 au groupe de volumes volume1

    # vgextend volume1 /dev/hdb2
    vgextend -- INFO:maximum logical volume size is 255.99 Gigabyte vgextend
    --doing automatic backup of volume group "volume1" vgextend
    --volume group "volume1" successfully extended

On pourra vérifier la bonne réalisation de l'opération grâce à la commande vgdisplay.

Redimensionner un volume logique

De la même façon, il est possible de diminuer ou augmenter la taille d'un volume logique au moyen des commandes lvreduce et lvextend.

lvextend -L taille /dev/nom_volume/vol_logique
vreduce -L taille /dev/nom_volume/vol_logique


nom_volume : nom du groupe de volume à redimensionner
dev/hdxx : volume physique à ajouter ou retirer du groupe de volumes
-L taille : taille finale du volume logique (aprè redimensionnement)

Les étapes à respecter pour redimensionner un volume logique :

  1. démontage du système de fichier (commande umount)
  2. réduction / augmentation de la taille du système de fichiers: on utilisera pour cela un utilitaire fourni dans le package LVM
  3. réduction / augmentation de la taille du volume logique
  4. remontage du système de fichiers

Si l'on veut augmenter l'espace du volume logique part1 en passant de 600 à 800 Mo , il ne nous restera plus qu'à proceder de la maniere suivante :

# lvextend -L 800 /dev/volume1/part1
lvextend -- extending logical volume "/dev/volume1/part1" to 800 MB
lvextend -- doing automatic backup of volume group "volume1"
lvextend -- logical volume "/dev/volume1/part1" successfully extended

Là encore on pourra vérifier le bon déroulement de l'opération grâce aux commandes lvdisplay pour le volume logique et df pour le système de fichiers. Les remarques ci-dessus sont une description générale de l'opération. Ces étapes peuvent toutefois varier en fonction du système de fichiers utilisé. Certains procurent en effet la possibilité d'effectuer les opérations de redimensionnement "à chaud" c'est-à-dire sans démontage. Ci-contre un tableau comparatif des différents systèmes de fichiers les plus couramment rencontrés (Tableau 1)

Tableau 1 : manipulation des systèmes de fichiers

Système de fichiers diminution Augmentation Utilitaires
ext3 démontage préalable démontage préalable e2fsprogs (resize2fs)
ReiserFS démontage préalable opération on-line reiserfsprogsv (resize_reiserfs)
XFS impossible opération on-line xfsprogs (xfs_growfs)

Une fonction particulière du LVM : la réalisation de snapshots

La difficulté fréquemment rencontrée pour la réalisation de sauvegardes est de disposer de données cohérentes. Cela implique parfois d'arrêter un ou plusieurs services comme dans le cas des bases de données. Le LVM apporte un élément de réponse avec la possibilité de créer des snapshots. Il s'agit d'image à un moment t des données situées sur un volume logique. Le volume de snapshot ne nécessite pas autant d'espace que le volume initial dans la mesure où il ne contiendra réellement que les métadatas concernant les données à sauvegarder.

Autres commandes

Cet article n'abord era pas le détail de toutes les commandes, qui sont plutôt simples à utiliser une fois que les concepts de base du LVM sont compris. Dans le tableau ci-aprè une liste de commandes utilisables et la description rapide de leur rôle. Voir le man de la commande pour plus d'informations.

Commandes générales

  • lvmcreate_initrd : création d'une image initrd lorsque le système utilise le LVM
  • lvmdiskscan : scanner l'ensemble des disques et partitions pour éditer une description de l'espace
  • vgscan : création de /etc/lvmtab et /etc/lvmtab.d
  • Gestion des volumes physiques

  • pvchange : changer les attributs d'un PV
  • pvcreate : création d'un PV
  • pvdata : afficher des informations de debug
  • pvdisplay : afficher des informations d'un PV
  • pvscan : lister tous les PV existant sur tous les disques
  • Gestion des groupes de volumes

  • vgcfgbackup : sauvegarder la VGDA
  • vgcfgrestore : restaurer la VGDA
  • vgchange : changer les attributs d'un VG
  • vgck : vérification de la VGDA
  • vgcreate : créer un VG
  • vgdisplay : voir les informations
  • vgexport : désactiver un VG pour pouvoir extraire les PV
  • vgimport : activer et déclarer un VG sur le système
  • vgextend : ajouter un ou plusieurs PV dans un VG
  • vgmerge : fusionner deux VG
  • vgmknodes : recréer /dev/nom_volume et le fichier spécial group
  • vgreduce : extraire un ou plusieurs PV d'un VG
  • vgremove : supprimer un VG
  • vgrename : renommer un VG
  • Gestion des volumes logiques

  • lvcreate : création d'un VL lvchange : modification des attributs d'un VL
  • lvdisplay : voir les informations d'un VL
  • lvextend : augmenter la taille d'un VL
  • lvreduce : réduire la taille d'un VL
  • lvremove : supprimer un VL
  • lvrename : renommer un VL
  • lvscan : recherche de tous les VL existant
  • Utilisation pratique du LVM dans la gestion de l'espace

    Vous diposez d'un groupe de volume dans lequel vous n'avez plus d'espace disponible. Pour pouvoir augmenter un des volumes logiques, il va donc falloir ajouter un disque au groupe de volume. Comme pour tout élément du LVM, la première étape consiste à le transformer en volume physique ("pvcreate"). Puis on va insérer le nouveau volume physique dans le groupe de volume au moyen de la commande "vgextend". C'est tout !

    Plus complexe, vous pouvez, pour quelle que raison que ce soit, envisager de déplacer un groupe de volume d'une machine à une autre. Si une sauvegarde de données est toujours conseillée par sécurité (mais comme vous êtes prévoyant vous en disposez de toute façon ;)), l'opération va consister à désactiver le groupe de volume à déplacer, enregistrer les métadatas le concernant. Puis on va réinjecter ces métadatas sur la machine destinataire et réactiver le groupe de volume sur cette machine. Les données seront alors accessibles de la même façon que sur l'ancienne machine (sous réserve de conserver les mêmes points de montage).

    Ci-dessous les étapes effectuées :

    1. désactivation du groupe de volume ("datas") :
      # vgchange n datas
    2. sauvegarde des métadatas du groupe de volume :
      # vgcfgbackup datas
    3. retrait du groupe de volume de la configuration système :
      # vgexport datas
    4. arrêt de la première machine, transfert des disques dans la deuxième et redémarrage des machines
    5. restauration des métadatas concernant ce groupe de volume sur la nouvelle machine :
      # vgcfgrestore -f datas.conf /dev/hda3
      # vgcfgrestore -f datas.conf /dev/hda4
      si les volumes physiques sont hda3 et hda4.
    6. déclaration du groupe de volume sur la machine :
      # vgimport datas /dev/hda3 /dev/hda4
    7. activation du groupe de volume importé :
      # vgchange y datas

    Il ne vous reste plus qu'à modifier en conséquence /etc/fstab pour le montage automatique des systèmes de fichiers contenus dans le groupe de volume.

    Evolution du LVM : LVM 2

    Avec la sortie du noyau 2.6, le LVM a été revu et corrigé et la version LVM2 est disponible de base avec ce noyau. Il est possible de l'utiliser avec un noyau 2.4.x moyennant recompilation de ce même noyau.

    Le device-mapper

    Le driver du LVM a été complètement réécrit, ce qui lui procure encore plus d'efficacité et de souplesse. La grande nouveauté réside dans l'utilisation de ce driver, utilisé pour gérer la couche d'abstraction nécessaire dans le cadre de la gestion de volumes logiques. Cette couche d'abstraction a pour fonction principale de réaliser le mapping résultant de l'agrégat par bandes (stripping) des périphériques physiques utilisés.

    Le device-mapper définit les nouveaux périphériques de bloc composés de tranches de secteurs de périphériques physiques existant. Le mapping réalisé prend la forme suivante :

    <start > < length > < target > [ < target args...>]

    Les targets peuvent être de plusieurs natures :

    Utilisation d'un arbre binaire

    Pour réaliser le mapping, un arbre binaire a été utilisé, ceci afin de rendre la lecture de la table plus rapide et donc le LVM plus efficace.

    Une plus grande configurabilité

    LVM2 peut fonctionner sans ajout de fichier de configuration mais l'emploi de celui-ci permet d'optimiser ses performances. Un certain nombre d'éléments peuvent ainsi être paramétrés :

    Compatibilité LVM1 / LVM2

    Il est possible d'utiliser conjointement LVM1 et 2 sur un même système, et/ou de convertir du LVM 1 en 2 et inversement.

    On peut effectivement utiliser sur un même système les deux versions de LVM, à condition que ce ne soit pas dans le même groupe de volumes. Les commandes LVM ont en effet un commutateur supplémentaire, -M, qui permet de faire ce choix. (-M 1 ou -M 2)

    D'autre part, la comande vgconvert permet la conversion des métadatas pour migrer de LVM1 à LVM2

    Autre

    LVM2 permet d'assouplir encore plus la gestion de l'espace, dans la manipulation des volumes logiques. La commande lvcreate par exemple donne maintenant la possibilité de choisir le périphériques voire la tranche de PE à utiliser.

    En conclusion...

    Voilà donc un outil de plus qui fait qu'un système Linux peut être véritablement efficace et optimiser la disponibilité d'un serveur en production. L'outil LVM peut également être utilisé avantageusement sur un poste personnel, pour s'éviter les opérations fastidieuses liées à la gestion de l'espace disque.

    Liens utiles

    Haut


    QoS/Gestion de la bande passante sous Linux

    par julien Lecubin


    Introduction

    Dans cet article, je vais vous expliquer les différentes étapes pour mettre en place la QoS et gérer votre bande passante sous Linux.

    Pourquoi faire de la QoS ? Retenez que sans la QoS, vous ne pouvez pas gérer correctement les flux qui transitent sur votre réseau. Vous aurez par exemple des problèmes à écouter un flux audio en streaming sachant qu'en même temps, vous êtes en train de faire du ftp. Dans la première partie de cet article, je vais vous montrer comment prioriser les divers flux de votre réseau.

    Pourquoi gérer la BP de mon réseau ? Une personne qui fait du ftp sur une ligne ADSL de bureau peut monopoliser à elle seule toute la bande passante en sortie de votre réseau. Ce cas ne se limite pas aux réseaux ADSL et peut être aussi constaté sur des réseaux à très haut débit (lignes de type T1/T2). Linux peut apporter une solution efficace face à ce genre de problème en vous offrant la possibilité de gérer intelligemment votre bande passante. Ce sera le sujet de la deuxième partie de ce présent document.

    Actuellement, sachez que vous pouvez faire de la QoS et de la gestion de bande passante sous les noyaux 2.2 et 2.4. Néamoins, pour une question de facilité, je vous recommande un noyau 2.4 pour effectuer ce qui suit.

    QoS via iptables

    Pour faire de la QoS, nous allons modifier la valeur du champs TOS se situant dans l'en tête IP grâce à iptables. Le champ TOS est sur 4 bits :

    HEXA BINAIRE DECIMAL SIGNIFICATION
    0x10 1000 8 Minimize Delay
    0x08 0100 4 Maximize throughput
    0x04 0010 2 Maximize reliability
    0x02 0001 1 Minimize monetary cost
    0x00 0000 0 Normal

    L'intêret de la QoS sous Linux est très souvent associé à la priorisation de flux interactifs via iptables. Par exemple, vous ne souhaitez pas que votre session ssh soit interrompue à cause d'un utilisateur qui est en train de monopoliser la bande passante de votre réseau en downloadant une bande annonce sur internet (Il s'agit d'un cas de figure bien plus répandu qu'on ne le pense !). Nous allons ici à titre d'exemple optimiser les trafics courants avec iptables, à savoir le ftp et ssh :

    # Priorisation des connexions ftp et ssh
    iptables -A PREROUTING -t mangle -p tcp --sport ssh -j TOS --set-tos Minimize-Delay
    iptables -A PREROUTING -t mangle -p tcp --sport ftp -j TOS --set-tos Minimize-Delay
    # On donne un maximum de débit aux transferts ftp, peu importe la latence
    iptables -A PREROUTING -t mangle -p tcp --sport ftp-data -j TOS --set-tos Maximize-Throughput

    A vous d'adapter ce script suivant les services de votre réseau que vous souhaitez prioriser.

    Gestion de la bande passante sous Linux

    Nous abordons la deuxième partie du document. Linux utilise deux unités du contrôle de trafic pour la gestion de la bande passante :

    Gardez en vue que le protocole TCP/IP n'a pas d'aptitude à connaître les performances d'un réseau. Il commence à envoyer des paquets, de plus en plus rapidement et quand des paquets commencent à se perdre, il ralentit. La plupart des files d'attentes fonctionnent selon le modèle suivant : elles recoivent des paquets, les positionnent en file d'attente jusqu'à un certain point, et ensuite, éliminent tout paquet qui arrive dans le cas où la file d'attente est pleine. Si on travaille en UDP, les paquets ne sont plus retransmis, si c'est du TCP, l'émetteur renverra les paquets perdus. Le débit s'en trouve alors ralenti.

    Compilation du noyau

    Nous allons compiler le noyau afin que celui-ci sache gérer notre BP ( = Bande Passante). Si vous avez une ditribution récente, il se peut que vous n'ayez pas besoin de le compiler. Lancez un "make xconfig" sous le X dans le répertoire /usr/src/linux. Si cela ne marche pas, installez les sources du noyau (le rpm est du type kernel-src-*.rpm)

    Les options

    Dans la partie "Networking Options" -> "QoS and fair queuing" :

    Option Noyau Sélection à la Compilation Définition
    QoS & fair queuing oui
    Netfilter module Network Packet Filtering
    CBQ packet scheduler module (Classed Based Queue) - file d'attente basée sur des classes. C'est ce type de file d'attente qui sera implémentée dans la suite du présent document
    HTB packet scheduler module (Hierarchical Token buckets) implémenté dans la suite du présent document - Si vous ne l'avez pas, j'explique plus bas comment avoir cette file d'attente en patchant votre noyau
    CSZ packet scheduler module (Clark-Shenker-Zhang) - Les flux ne sont pas limités à leur bande passante. Fournit un service garanti
    The simplest PRIO pseudoscheduler module
    RED queue module (Random Early Detect) - Anticipe les problèmes de congestion. RED élimine les paquets pour indiquer à TCP/IP de ralentir - Pour de gros débits
    SFQ queue module (Stochastic Fair Queuing) - Limitation basée sur le taux de transfert utilisé - Consomme peu de CPU/Mem. Rapide, peu précis. Efficace sur de gros débits - Offre un traitement sensiblement équitable de chaque classe
    TBF queue module Consomme peu de CPU. Limitation basée sur le taux de transfert à utiliser - Non basé sur les classes
    Ingress QDisc module (Queuing discipline) - Indispensable lorsque l'on souhaite utiliser les files d'attente
    QoS support oui
    Rate estimator oui
    Packet classifier API oui
    TC Index classifier module
    Routing table based classifier module
    Firewall based classifier module
    U32 classifier module
    Special RSVP classifier module
    Special RSVP classifier for IPv6 module

    Les files d'attentes les plus importantes sont CBQ et HTB (la suite du document se base sur ces deux files d'attente). Vous n'êtes pas obligé de mettre en module les autres files d'attentes (CSZ, RED, SFQ, TBF, TEQL), cependant, cela reste toujours intéressant de les laisser en tant que module au cas où vous en auriez besoin plus tard.

    Terminer la compilation

    Compilez le noyau par :

    Ensuite :

    Allez prendre un café
    Toujours pas fini ? Retournez prendre un café... :)
    cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz
    cp /usr/src/linux/arch/i386/boot/System.map /boot

    Modifiez /etc/lilo.conf pour prendre en compte le nouveau noyau et lancez la commande "lilo".

    Assurez-vous enfin que votre station Linux comporte la commande "tc" (un "which tc" vous permettra de voir si "tc" est installé). Si vous ne l'avez pas, elle fait partie du package iproute2 (les sources sont ici et le rpm peut être téléchargé )

    Désormais, votre noyau linux implémente la gestion de bande passante. Il ne reste plus qu'à écrire un script propre à votre config, ce qui est décrit dans la suite du document.

    Scripts de gestion de bande passante CBQ.init, HTB.init et wshaper.htb

    Si vous souhaitez partager votre bande passante sans trop vous compliquer la vie, sachez que des scripts on été créés afin d'optimiser votre bande passante. Dans la suite du document, je vais vous expliquer comment les mettre en place. Lisez bien la définition de chacun de ces scripts, de manière à définir celui qui vous convient le mieux.

    CBQ.init : file d'attente CBQ

    HTB.init : file d'attente HTB Wondershaper : file d'attente HTB

    Remarque : Sachez que souvent, on préconise l'utilisation de files d'attentes de type HTB plutot que CBQ. Cependant, si votre distribution n'est pas très récente, il y aura pas mal de choses à réaliser pour implémenter les files d'attentes HTB sur votre station (j'explique neanmoins la démarche à suivre si vous êtes dans ce cas).

    CBQ.init

    Récupérez le script à l'adresse suivante :

    https://sourceforge.net/projects/cbqinit

    Faites un "chmod u+x CBQ.init*" afin de le rendre executable.
    Copiez le script dans le répertoire /usr/bin : "cp CBQ.init-[VERSION] /usr/bin"
    Créez le répertoire /etc/sysconfig/cbq qui contiendra les options de gestion de BP sur lequelles se basera le script : "mkdir /etc/sysconfig/cbq" - Si vous souhaitez placer vos fichiers de configurations CBQ ailleurs, modifiez la variable $CBQ_PATH dans le script CBQ.init afin de renseigner le nouveau chemin.

    Exemples de fichiers de configurations pour le script CBQ.init :

    Les fichiers de configuration doivent respecter une syntaxe précise de type cbq-CLASS_ID.name où CLASS_ID est compris en hexa entre 0002 et FFFF (pour en savoir plus, editez le script, c'est expliqué en détail).

    Exemple 1 : $CBQ_PATH/cbq-1280.My_first_shaper - vous avez 2 interfaces (eth0=LAN et eth1=INTERNET) sur votre machine et souhaitez limiter le trafic INTERNET -> LAN à 16 Ko/s

    DEVICE=eth0,10Mbit,1Mbit # 10 Mbits -> debit max de votre interface eth0
    RATE=128Kbit # Exprimez les valeurs en Kbit ou Mbit selon les débits spécifiés
    WEIGHT=10Kbit # WEIGHT = RATE / 10
    PRIO=5 # Va de 1 à 8 , 1 etant le + prioritaire (la valeur 5 est recommandée et suffisante pour prioriser un traffic spécifique)
    RULE=192.168.1.0/24

    Exemple 2 : $CBQ_PATH/cbq-1280.My_second_shaper - vous avez 1 interface sur votre machine (eth0-192.168.1.5) et souhaitez limiter le trafic MACHINE -> INTERNET à 16 Ko/s

    DEVICE=eth0,10Mbit,1Mbit # La limite du traffic s'effectue sur l'interface 10 Mbits/s eth0
    RATE=128Kbit
    WEIGHT=10Kbit
    PRIO=5
    RULE=192.168.1.5, # Attention à la ',' cela permet de specifier qu'il s'agit d'une d'adresses source ! Ici, la limitation de BP s'applique uniquement à la machine 192.168.1.5

    Exemple 3 : $CBQ_PATH/cbq-1280.My_third_shaper - vous souhaitez limiter le traffic de votre serveur web (192.168.1.50) à 8 Ko/s

    DEVICE=eth0,10Mbit,1Mbit # 10 Mbits -> debit max de l'interface de votre serveur web
    RATE=64Kbit # Exprimez les valeurs en Kbit ou Mbit selon les débits spécifiés
    WEIGHT=6Kbit # WEIGHT = RATE / 10
    PRIO=5 # Va de 1 à 8 , 1 etant le + prioritaire (la valeur 5 est recommandée et suffisante pour prioriser un traffic spécifique)
    RULE=192.128.1.50:80,

    Exemple 4 : $CBQ_PATH/cbq-1280.My_fourth_shaper - vous souhaitez limiter le traffic des gens qui download sur votre serveur ftp (192.168.1.50) à 10 Ko/s

    DEVICE=eth0,10Mbit,1Mbit # 10 Mbits -> debit max de l'interface de votre serveur ftp
    RATE=80Kbit # Exprimez les valeurs en Kbit ou Mbit selon les débits spécifiés
    WEIGHT=8Kbit # WEIGHT = RATE / 10
    PRIO=5 # Va de 1 à 8 , 1 etant le + prioritaire (la valeur 5 est recommandée et suffisante pour prioriser un traffic spécifique)
    RULE=192.128.1.50:20/0xfffe # limitation de BP appliquée sur port 20/21

    Exemple 5 : $CBQ_PATH/cbq-1280.My_fifth_shaper - vous souhaitez que le traffic LAN -> INTERNET soit limité à 50 Ko/s (400 Kbits/s), et que le traffic INTERNET -> LAN soit limité à 10Ko/s (80 Kbits/s), remplissez CBQ.init de la manière suivante :

    LAN ----- eth0 [LINUX] eth1 ----- INTERNET
    ######################## {{ LAN -> INTERNET }} ####################################
    DEVICE=eth1,10Mbit,1Mbit
    RATE=400Kbit
    WEIGHT=40Kbit # WEIGHT = RATE / 10
    PRIO=5
    BOUNDED=yes # Pour ne pas aller prendre de la BP aux classes parents
    ISOLATED=NO # Permet de léguer de la BP aux classes filles si il en reste
    RULE=192.168.0.0/24 # Le partage de BP concerne le traffic a destination du reseau 192.168.0.0
    ############################################################ ############
    ######################## {{ INTERNET -> LAN }} ####################################
    DEVICE=eth0,100Mbit,10Mbit #
    RATE=80Kbit # On souhaite limiter le traffic entrant à 10 Ko/s (adaptez selon le debit de votre ligne)
    WEIGHT=8Kbit # WEIGHT = RATE / 10
    PRIO=5
    BOUNDED=yes
    ISOLATED=NO
    RULE=80,192.168.1.10 # Tout le traffic HTTP INTERNET -> 192.168.1.10 limité à 10 Ko/s
    #################################### ####################################

    Il ne reste plus qu'à lancer le script CBQ.init à chaque démarrage ; pour cela éditez le /etc/rc.d/rc.local et ajoutez la ligne "CBQ.init-[version] start" où [version] désigne la version de votre script CBQ.
    Si vous souhaitez obtenir des statistiques CBQ, lancez la commande "CBQ.init-[VERSION] stats". Le script vous sortira des informations qui peuvent s'avérer utile.

    Voilà, vous êtes désormais un gourou des files d'attentes CBQ :). Passons maintenant à la gestion de la BP avec file d'attentes HTB.

    HTB.init

    Récupérez le script HTB.init à l'adresse suivante : http://sourceforge.net/projects/htbinit

    Notes pour noyau < 2.4.18-3 : pour utiliser des files d'attentes HTB, sachez que vous devez patcher votre noyau si il est inférieur à la version 2.4.18-3 (tapez "uname -a" pour vérifier la version de votre distribution) :
    http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.4.17.diff pour les noyaux 2.4
    http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.2.17.diff pour les noyaux 2.2

    Pour appliquer le patch lancez la commande suivante dans le répertoire /usr/src/linux : "patch -pl -i htb2_2.4.17.diff"
    Dans /usr/src/linux tapez : "make xconfig"
    Dans la partie "Networking Options" -> "QoS and fair Queuing", selectionnez HTB packet scheduler en module
    Recompilez le noyau : "make dep && make clean && make bzImage && make modules && make modules_install"
    Mettez en place le nouveau noyau qui prend en charge HTB :

    cp /usr/src/linux/arch/i386/bzImage /boot/vmlinuz
    cp /usr/src/linux/arch/i386/boot/System.map /boot

    Vous devez aussi mettre à jour la commande "tc" : http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz

    Faites un "chmod u+x HTB.init-[VERSION]" afin de le rendre executable.
    Copiez le script dans le répertoire /usr/bin : "cp HTB.init-[VERSION] /usr/bin"
    Créez le répertoire /etc/sysconfig/htb qui contiendra les fichiers de gestion de BP sur lequelles se basera le script : "mkdir /etc/sysconfig/htb" - Si vous souhaitez placer vos fichiers de configurations HTB ailleurs, modifiez la variable $HTB_PATH dans le script HTB.init afin de renseigner le nouveau chemin.

    Exemples de fichiers de configurations HTB.init :

    Il n'existe pas un mais plusieurs fichiers de configurations pour HTB.init. Les fichiers doivent obligatoirement avoir une syntaxe précise. Par exemple :

    eth0-2 -> classe root ID 2, device eth0
    eth0-2:3 -> classe fille ID 3, ayant comme parent 2, device eth0
    eth0-2:3:4 -> classe fille ID 4, ayant comme parent 3, device eth0
    eth1-2.root -> classe root ID 2, device eth1

    Remarque : Une autre notation en cas d'erreur lors de la creation de ce type de fichiers : eth0-2\:3 -> Vous placez un "\" avant le ":"

    Cela peut paraître un peu confu comme syntaxe, cependant, je vais vous donner des exemples. Editez le script si vous souhaitez néanmoins en savoir plus à ce sujet.
    Avec ce type de files d'attentes, vous ne pouvez realiser un contrôle de flux qu'en sortie de vos interfaces réseaux. Dans le cas d'une station qui fait du routage, configurez les débits sur les sorties des deux interfaces (voir exemple 2).

    Exemple 1 :

    Imaginons que vous ayez une bande passante sur votre station de 5 Mbits/s (~600Ko/s). Vous souhaitez :

    5Mbits/s pour le HTTP,
    3Mbits/s pour le SMTP
    1Kbit/s pour le traffic divers (qui vous importent peu)
    Dans le cas où il y a de la bande passante de libre, vous souhaitez la partager entre le SMTP et traffics divers.
    SMTP pourra utiliser tout le temps au moins 3Mbits/s et pourra monter jusqu'à 5 Mbits/s si il y a de la BP de libre.
    Le traffic divers pourra utiliser tout le temps au moins 1Kbit/s et pourra monter jusqu'à 5Mbits/s si il y a de la BP de libre.

    Allez dans le répertoire /etc/sysconfig/htb ($HTB_PATH) et placez-y les lignes suivantes pour chaque fichier :


    fichier eth0
    DEFAULT=30 # ID class default - Le traffic non répertorié utilisera la class ID 30

    fichier eth0-2.root
    RATE=5Mbit # Bande passante allouée a la classe root (ici 5Mbits)
    BURST=15k

    fichier eth0-2:10.www
    RATE=5Mbit
    BURST=15k
    LEAF=sfq # Type de file d'attente utilisée par cette classe (ici sfq)
    RULE=*:80, # Voir les exemples du script CBQ.init - La syntaxe "RULE" est identique

    fichier eth0-2:20.smtp
    RATE=3Mbit
    CEIL=5Mbit # La bande passante max de cette classe peut aller jusqu'a 5 Mbits/s uniquement si il y a de la BP de libre.
    BURST=15k
    LEAF=sfq
    RULE=*:25

    fichier eth0-2:30.dfl
    RATE=1Kbit
    CEIL=5Mbit
    BURST=15k
    LEAF=sfq

    Exemple 2 :

    On traite ici le cas d'une personne ayant une connexion ADSL de type 512/128. Sa connexion se fait via une machine-routeur possédant deux interfaces (eth0 et eth1). Elle souhaite limiter l'upload à 90 Kbits/s (11,3 Ko/s) et donner la priorité aux services HTTP, SSH, TELNET, POP3, SMTP et DNS. Une priorité plus petite sera attribuée à tout autre traffic. Côté, download on garde la même idée, cependant, la limite sera fixée à 450 Kbits/s (57 Ko/s).

    Allez dans le répertoire /etc/sysconfig/htb ($HTB_PATH) et placez-y les lignes suivantes pour chaque fichier :

    fichier eth1 (Tous fichier de type eth1* -> traffic sortant de l'interface eth1)
    DEFAULT=30
    R2Q=1

    fichier eth1-2.root
    #Classe root pour traffic sortant
    RATE=90Kbit

    fichier eth1-2\:10.high
    # Classe pour traffic sortant de haute priorité
    RATE=30Kbit
    CEIL=prate
    LEAF=sfq
    #HTTP
    RULE=*:80
    #SSH
    RULE=*:22
    #TELNET
    RULE=*:23
    #SMTP
    RULE=*:25
    #DNS
    RULE=*:53
    #POP3
    RULE=*:110

    fichier eth1-2\:20.normal
    # Classe pour traffic sortant normal
    RATE=30kbit
    CEIL=prate
    LEAF=sfq
    #IRC
    RULE=*:6667

    fichier eth1-2\:30.low
    # Classe pour traffic sortant peu important
    RATE=20Kbit
    CEIL=prate
    LEAF=sfq
    #EMULE
    RULE=*:3000
    RULE=*:3000,
    RULE=*:3010
    RULE=*:3010,
    RULE=*:4662 RULE=*:4662,

    fichier eth0 (Tous fichier de type eth0* -> traffic sortant de l'interface eth0)
    DEFAULT=30
    R2Q=10

    fichier eth0-2\:10.high
    # Classe pour traffic sortant de haute priorité
    RATE=150 Kbit
    CEIL=prate
    LEAF=sfq
    #HTTP
    RULE=*:80,
    #SSH
    RULE=*:22,
    #TELNET
    RULE=*:23,
    #SMTP
    RULE=*:25,
    #DNS
    RULE=*:53,
    #POP3
    RULE=*:110,

    fichier eth0-2\:20.normal
    # Classe pour traffic sortant normal
    RATE=30kbit
    CEIL=prate
    LEAF=sfq
    #IRC
    RULE=*:6667,

    fichier eth0-2\:30.low
    # Classe pour traffic sortant peu important
    RATE=150Kbit
    CEIL=prate
    LEAF=sfq
    #EMULE
    RULE=*:3000,
    RULE=*:3010,
    RULE=*:4662,
    RULE=*:3000
    RULE=*:3010
    RULE=*:4662
    RULE=*:4662
    RULE=*:4662,

    Il ne reste plus qu'à lancer le script HTB.init à chaque démarrage ; pour cela éditez le /etc/rc.d/rc.local et ajoutez la ligne "HTB.init-[version] start" où [VERSION] désigne la version de votre script HTB.
    Si vous souhaitez obtenir des statistiques HTB, lancez la commande "HTB.init-[VERSION] stats". Le script vous sortira des informations qui peuvent s'avérer utile.

    wondershaper
    Récupérez wondershaper à l'adresse suivante :

    http://lartc.org/wondershaper

    Editez le script wshaper et indiquez les débits ; par exemple pour une ligne ADSL 512/128 :

    DOWNLINK= 500
    UPLINK= 100
    DEV=ppp0

    Désormais, votre machine avec ce script :

    J'ai trouvé sur internet un script dérivé de Wondershaper, il peut s'avérer intéressant de le mettre en oeuvre si vous avez une connexion de type ADSL. En revanche, ce script fait appel à de nombreuses files d'attentes : CBQ, RED, IMQ, HTB et SFQ (Assurez-vous au préalable que votre noyau les prend toutes en compte).

    #!/bin/bash
    #
    # mon_limiteur - Limiteur et classificateur de trafic pour modem Cable ou ADSL.
    # Inspiré de WonderShaper (www.lartc.org)
    #
    # Écrit par Dan Singletary (7/8/02)
    #
    # Remarque - ce script suppose que le noyau a été patché avec les files
    # HTB et IMQ disponibles ici (les noyaux à venir ne demanderont
    # pas forcément l'application d'un correctif):
    # http://luxik.cdi.cz/~devik/qos/htb/
    # http://luxik.cdi.cz/~patrick/imq/
    #
    # Options de configuration pour mon_limiteur:
    # DEV - correspond au périphérique ethX connecté au modem
    # RATEUP - à positionner à une valeur inférieure à la bande
    # passante montante de la ligne.
    # Pour ma ligne ADSL en 1500/128, RATEUP=90 convient au rythme
    # montant de 128 kbps. À vous d'ajuster.
    # RATEDN - à positionner en dessous de la bande passante descendante de
    # la ligne.
    #
    #
    # Principe d'utilisation d'imq pour limiter le trafic entrant:
    #
    # Il est impossible de limiter directement le rythme auquel les
    # données vous sont envoyées depuis l'Internet. Afin de limiter le
    # trafic entrant, on s'appuie sur les mécanismes anti-congestion de
    # TCP. Ceci signifie que SEUL LE TRAFIC TCP PEUT SE LIMITER. Le
    # trafic hors TCP est placé dans une queue prioritaire car le jeter
    # ne conduit vraisemblablement qu'à une retransmission ultérieure
    # qui accroît la bande passante consommée.
    # On limite le trafic TCP en jetant les paquets lorsqu'ils débordent
    # de la file HTB qui les limitera à un certain rythme (RATEDN)
    # légèrement inférieur à la capacité réelle de la ligne. Jeter ces
    # paquets revient à en singer la perte par la file d'émission du
    # côté du FAI. Ceci a l'avantage d'éviter la congestion de la file
    # d'émission chez le FAI puisque TCP ralentira avant qu'elle ne
    # se remplisse. L'usage d'une stratégie de mise en attente basée sur
    # la classification des paquets par priorité permet de ne PAS jeter
    # certains types de paquets (ssh, telnet, etc). Les paquets ne sont
    # retirés des files d'attente de faible priorité qu'une fois que
    # chaque classe a atteint un seuil minimum (1/7 de la bande passante
    # dans ce script).
    #
    # Résumé:
    # * La perte d'un paquet TCP diminue le rythme de réception de la
    # connexion associée via les mécanismes de contrôle de congestion.
    # * Jeter des paquets TCP n'apporte rien. S'ils sont importants, ils
    # seront retransmis.
    # * Limiter le rythme des connexions TCP entrantes en dessous de la
    # capacité de la ligne DEVRAIT éviter la mise en attente des paquets
    # du côté du FAI (DSLAM, concentrateur de cables, etc). L'expérience
    # indique que ces files contiennent 4 secondes de trafic à 1500 kbps,
    # soit 6 Mb de données. À ce niveau, l'absence de mise en attente
    # diminue la latence.
    #
    # Avertissements:
    # * Est-ce que la limitation de bande passante diminue l'efficacité de
    # transferts TCP massifs ?
    # - Apparemment non. L'augmentation de priorité des paquets
    # d'acquittement maximise le débit en évitant de perdre de la bande
    # passante à retransmettre des paquets déjà reçus.
    #

    # NOTE: La configuration ci-dessous fonctionne avec ma connexion ADSL
    # 1.5M/128K via Pacific Bell Internet (SBC Global Services)

    DEV=eth0
    RATEUP=90
    RATEDN=700 # Nettement inférieur à la capacité de la ligne de 1500.
    # On n'a donc pas à limiter le trafic entrant jusqu'à ce
    # qu'une meilleure réalisation telle que la modification
    # de fenêtre TCP soit disponible.

    #
    # Fin des options de configuration
    #

    if [ "$1" = "status" ]
    then
    echo "[qdisc]"
    tc -s qdisc show dev $DEV
    tc -s qdisc show dev imq0
    echo "[class]"
    tc -s class show dev $DEV
    tc -s class show dev imq0
    echo "[filter]"
    tc -s filter show dev $DEV
    tc -s filter show dev imq0
    echo "[iptables]"
    iptables -t mangle -L MONLIMITEUR-OUT -v -x 2> /dev/null
    iptables -t mangle -L MONLIMITEUR-IN -v -x 2> /dev/null
    exit
    fi

    # Remise à zéro
    tc qdisc del dev $DEV root 2> /dev/null > /dev/null
    tc qdisc del dev imq0 root 2> /dev/null > /dev/null
    iptables -t mangle -D POSTROUTING -o $DEV -j MONLIMITEUR-OUT 2> /dev/null > /dev/null
    iptables -t mangle -F MONLIMITEUR-OUT 2> /dev/null > /dev/null
    iptables -t mangle -X MONLIMITEUR-OUT 2> /dev/null > /dev/null
    iptables -t mangle -D PREROUTING -i $DEV -j MONLIMITEUR-IN 2> /dev/null > /dev/null
    iptables -t mangle -F MONLIMITEUR-IN 2> /dev/null > /dev/null
    iptables -t mangle -X MONLIMITEUR-IN 2> /dev/null > /dev/null
    ip link set imq0 down 2> /dev/null > /dev/null
    rmmod imq 2> /dev/null > /dev/null

    if [ "$1" = "stop" ]
    then
    echo "Limitation de débit désactivée sur $DEV."
    exit
    fi

    ###########################################################
    #
    # Limitation de trafic sortant (limite supérieure à RATEUP)

    # positionnement de la taille de la file d'émission pour obtenir
    # une latence d'environ 2 secondes pour les paquets de la file
    # de faible priorité.
    ip link set dev $DEV qlen 30

    # modification de MTU du périphérique sortant.
    # - Diminuer la MTU abaisse la latence mais dégrade le débit en raison de
    # la surcharge IP et TCP.
    ip link set dev $DEV mtu 1000

    # ajout de la stratégie HTB
    tc qdisc add dev $DEV root handle 1: htb default 26

    # ajout de la classe de limitation principale
    tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit

    # ajout des classes filles:
    # - chaque classe dispose AU MOINS de son quota de bande passante. Aucune
    # classe n'est donc étouffée par les autres. Chaque classe peut également
    # consommer toute la bande passante si aucune autre classe ne l'emploie.
    tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[$RATEUP/7]kbit \
    ceil ${RATEUP}kbit prio 0
    tc class add dev $DEV parent 1:1 classid 1:21 htb rate $[$RATEUP/7]kbit \
    ceil ${RATEUP}kbit prio 1
    tc class add dev $DEV parent 1:1 classid 1:22 htb rate $[$RATEUP/7]kbit \
    ceil ${RATEUP}kbit prio 2
    tc class add dev $DEV parent 1:1 classid 1:23 htb rate $[$RATEUP/7]kbit \
    ceil ${RATEUP}kbit prio 3
    tc class add dev $DEV parent 1:1 classid 1:24 htb rate $[$RATEUP/7]kbit \
    ceil ${RATEUP}kbit prio 4
    tc class add dev $DEV parent 1:1 classid 1:25 htb rate $[$RATEUP/7]kbit \
    ceil ${RATEUP}kbit prio 5
    tc class add dev $DEV parent 1:1 classid 1:26 htb rate $[$RATEUP/7]kbit \
    ceil ${RATEUP}kbit prio 6

    # ajout de la stratégie aux classes filles
    # - SFQ offre un traitement sensiblement équitable de chaque classe.
    tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
    tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 10
    tc qdisc add dev $DEV parent 1:22 handle 22: sfq perturb 10
    tc qdisc add dev $DEV parent 1:23 handle 23: sfq perturb 10
    tc qdisc add dev $DEV parent 1:24 handle 24: sfq perturb 10
    tc qdisc add dev $DEV parent 1:25 handle 25: sfq perturb 10
    tc qdisc add dev $DEV parent 1:26 handle 26: sfq perturb 10

    # répartition du trafic en classe via fwmark
    # - le trafic est réparti en classes de priorité suivant l'indicateur
    # fwmark des paquets (ceux-ci sont positionnés avec iptables un peu plus
    # loin). La classe de priorité par défaut a été mise à 1:26 de telle sorte
    # que les paquets qui ne sont pas marqués se retrouvent dans la classe de
    # priorité la plus faible.
    tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
    tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21
    tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:22
    tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 23 fw flowid 1:23
    tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 24 fw flowid 1:24
    tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 25 fw flowid 1:25
    tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26

    # ajout de MONLIMITEUR-OUT à la table de modification des paquets d'iptables
    # - ceci déclare la table employée pour filtrer et classer les paquets
    iptables -t mangle -N MONLIMITEUR-OUT
    iptables -t mangle -I POSTROUTING -o $DEV -j MONLIMITEUR-OUT

    # ajout de fwmark pour classer les différents types de trafic
    # - fwmark est positionné de 20 à 26 suivant la classe. 20 correspond à la
    # priorité la plus forte.

    # Trafic sur les ports bas
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --sport 0:1024 -j MARK --set-mark 23

    # Trafic sur les ports bas
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport 0:1024 -j MARK --set-mark 23

    # Port ftp-data, faible priorité
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport 20 -j MARK --set-mark 26

    # Messagerie Immédiate AOL
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport 5190 -j MARK --set-mark 23

    # ICMP (ping) - forte priorité (impressionnez vos amis)
    iptables -t mangle -A MONLIMITEUR-OUT -p icmp -j MARK --set-mark 20

    # DNS (petits paquets)
    iptables -t mangle -A MONLIMITEUR-OUT -p udp -j MARK --set-mark 21

    # shell sécurisé
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport ssh -j MARK --set-mark 22

    # shell sécurisé
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --sport ssh -j MARK --set-mark 22

    # telnet (hum ...)
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport telnet -j MARK --set-mark 22

    # telnet (hum ...)
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --sport telnet -j MARK --set-mark 22

    # IPSec - la surcharge n'est pas connue ...
    iptables -t mangle -A MONLIMITEUR-OUT -p ipv6-crypt -j MARK --set-mark 24

    # Serveur WWW local
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp --sport http -j MARK --set-mark 25

    # Petits paquets (des ACK probablement)
    iptables -t mangle -A MONLIMITEUR-OUT -p tcp -m length --length :64 -j MARK --set-mark 21

    # Répétition - on marque les paquets restants à 26 (faible priorité)
    iptables -t mangle -A MONLIMITEUR-OUT -m mark --mark 0 -j MARK --set-mark 26

    # Fin de la limitation sortante
    #
    ####################################################

    echo "Limitation de trafic sortant activé sur $DEV. Débit: ${RATEUP}kbit/sec."

    # Décommenter la ligne suivante pour n'avoir que la limitation de trafic montant.
    # exit


    #################################################### #
    # Limitation du trafic entrant (débit maximal de RATEDN)

    # on force le chargement du module imq

    modprobe imq numdevs=1

    ip link set imq0 up

    # ajout de la stratégie de mise en file d'attente
    # - par défaut une classe 1:21 à faible priorité

    tc qdisc add dev imq0 handle 1: root htb default 21

    # ajout de la classe de limitation principale
    tc class add dev imq0 parent 1: classid 1:1 htb rate ${RATEDN}kbit

    # ajout des classes filles
    # - trafic TCP en 21, le reste en 20
    #
    tc class add dev imq0 parent 1:1 classid 1:20 htb rate $[$RATEDN/2]kbit \
    ceil ${RATEDN}kbit prio 0
    tc class add dev imq0 parent 1:1 classid 1:21 htb rate $[$RATEDN/2]kbit \
    ceil ${RATEDN}kbit prio 1

    # ajout de la stratégie de limitation aux classes filles
    # - voir les remarques ci-dessus sur SFQ.
    tc qdisc add dev imq0 parent 1:20 handle 20: sfq perturb 10
    tc qdisc add dev imq0 parent 1:21 handle 21: red limit 1000000 \
    min 5000 max 100000 avpkt 1000 burst 50

    # répartition du trafic en classe via fwmark
    # - le trafic est réparti en classes de priorité suivant l'indicateur
    # fwmark des paquets (ceux-ci sont positionnés avec iptables un peu plus
    # loin). La classe de priorité par défaut à été mise à 1:26 de telle sorte
    # que les paquets qui ne sont pas marqués se retrouvent dans la classe de
    # priorité la plus faible.
    tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
    tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21

    # ajout de MONLIMITEUR-IN à la table de modification des paquets d'iptables
    iptables -t mangle -N MONLIMITEUR-IN
    iptables -t mangle -I PREROUTING -i $DEV -j MONLIMITEUR-IN

    # ajout de fwmark pour classer les différents types de trafic
    # - fwmark est positionné de 20 à 21 suivant la classe. 20 correspond à la
    # priorité la plus forte.

    # Forte priorité pour les paquets non TCP
    iptables -t mangle -A MONLIMITEUR-IN -p ! tcp -j MARK --set-mark 20

    # Les petits paquets TCP sont probablement des ACK
    iptables -t mangle -A MONLIMITEUR-IN -p tcp -m length --length :64 -j MARK --set-mark 20

    # shell sécurisé
    iptables -t mangle -A MONLIMITEUR-IN -p tcp --dport ssh -j MARK --set-mark 20

    # shell sécurisé
    iptables -t mangle -A MONLIMITEUR-IN -p tcp --sport ssh -j MARK --set-mark 20

    # telnet (hum ...)
    iptables -t mangle -A MONLIMITEUR-IN -p tcp --dport telnet -j MARK --set-mark 20

    # telnet (hum ...)
    iptables -t mangle -A MONLIMITEUR-IN -p tcp --sport telnet -j MARK --set-mark 20

    # Répétition - les paquets sans marque sont positionnés à 21 (faible priorité)
    iptables -t mangle -A MONLIMITEUR-IN -m mark --mark 0 -j MARK --set-mark 21

    # on envoie les paquets précédents à l'interface imq0.
    iptables -t mangle -A MONLIMITEUR-IN -j IMQ

    # Fin de la limitation de trafic entrant.
    #
    ####################################################

    echo "Limitation de trafic entrant activée sur $DEV. Débit: ${RATEDN}kbit/sec."

    Script de visualisation des files d'attentes

    Le script suivant visualise les files d'attentes :

    #!/bin/bash
    echo 'Qdisc'
    tc -s qdisc show dev eth0
    echo 'Classes'
    tc -s class show dev eth0
    echo 'Filter'
    tc -s filter show dev eth0

    Conclusion

    J'ai essayé à travers cet article de vous ammener un maximum de renseignements, cependant, je n'ai pas la prétention d'en faire un document référence (il y a l'excellent HOWTO QoS pour cela). Toutes les remarques sont les bienvenues, il serait intéressant de faire évoluer ce présent document avec les commentaires que vous y apporterez. Si vous avez des scripts HTB.init, ou CBQ.init perso, n'hesitez pas à me les envoyer, je les rajouterai dans cet article.

    Pour me contacter : guitarparts@fr.st

    Haut


    Crypter un système de fichiers

    par Meuh

    image d'une clé dans une serrure Depuis Linux version 2.4.22, le noyau stable intègre un ensemble d'algorithmes de cryptographie regroupés sous le nom de 'Scatterlist Cryptographic API'. Cette API est un 'backport' en provenance du kernel 2.5/2.6.

    Grâce à cette API et à une extension du device loop, il est possible de crypter un système de fichiers. Nous allons apprendre ici à l'installer et à la configurer.

    Il faut savoir qu'il existe deux versions d'API cryptographiques :

    À noter qu'il existe aussi la solution loop-AES développée par Jari Ruusu. Voir plus loin.

    Comment ça marche

    Le loop device permet de simuler un périphérique en mode bloc à partir d'un fichier. C'est grâce à ce driver que l'on peut monter les images de CD-ROM au format ISO9660 :

    # mount -t iso9660 -o loop monimage.iso /cdrom

    La cryptoloop insère les fonctions de cryptage dans les fonctions de lecture et d'écriture du loop device. Le loop device est donc utilisé pour convertir un fichier crypté en block device que l'on peut ensuite monter comme un disque normal. Tout ce qui est écrit sur ce système de fichier est crypté, autant les données que les méta-données (arborescence, noms de fichiers, droits d'accès, ...). L'accès aux fichiers est entièrement transparent, à part un temps d'accès plus important que l'accès direct.

    La cryptoloop utilise l'API de cryptographie afin d'avoir accès aux différents algorithmes de cryptage ('cypher') enregistrés. Parmi les cyphers disponibles dans la 'scatterlist cryptoapi', on citera : AES(Rijndael), Blowfish, Twofish, Serpent et l'antique DES.

    Prérequis

    Bien que les algorithmes de cryptage soient présents dans le kernel 2.4.22, il n'y a pour l'instant aucun driver permettant de crypter un fichier, un système de fichiers, un disque ou le swap. Il faut toujours un patch pour étendre les fonctionnalités du périphérique loop, ceci afin d'y insérer les fonctions de cryptage à la volée. Pour la version 2.4, sont donc nécessaires :

    Le premier patch apporte un nombre conséquent de changements au driver loop mais permet en contrepartie de crypter le swap. Le deuxième patch applique le minimum de changements pour permettre le cryptage/décryptage. L'auteur recommande l'usage du premier car il calcule correctement les tailles des volumes si l'on fait usage des offsets (voir plus loin).
    Quant à la prochaine version stable du kernel, la 2.6, tout y est présent : API cryptographique, crypto loop device et IPSec, donc pas de patch à appliquer.
    Ensuite, il est nécessaire de disposer des outils en adéquation avec la version de la cryptoloop/cryptoapi : vérifiez si vous votre système ne dispose pas des util-linux 2.12 : mount -V Si ce n'est pas le cas, il vous faut alors :

    Ou bien :

    À noter que Debian (3.0 Woody) fournit une version d'util-linux intégrant les patchs pour la cryptoapi de kerneli.org et est inutilisable pour notre usage.

    Remarque : Attention, lors de la mise à jour de vos outils, il est possible que d'une version (patch) d'util-linux à l'autre, la méthode pour étendre et/ou hasher le mot de passe peut être différente. Ce changement produisant alors un mot de passe incapable de décrypter vos données. L'auteur vous conseil d'utiliser les util-linux 2.12, nouvelle version qui va fixer la norme assurant la compatibilité future.

    Le kernel

    Pour les gens déjà au kernel 2.6, allez directement en 2.

    1. Appliquez le patch cryptoloop : patch-cryptoloop-jari-2.4.22.0 ou patch-cryptoloop-hvr-2.4.22.0 :

      $ cd /usr/src/linux
      $ bzcat <chemin>/patch-cryptoloop-<version>-2.4.22.0.bz2 | patch -p1 -E

    2. Configurez le kernel : make menuconfig ou make xconfig Section [Block devices] : activez les modules correspondants aux périphériques loop et cryptoloop. Section [Cryptographic options] : activez le support de la crypto : tous les cyphers en modules
    3. Si vous n'utilisiez pas déjà le kernel 2.6 ou 2.4.22 avec le support du loop device en module ou que l'opération de chargement a échoué, il faut recompiler un noyau : utilisez la commande correspondant à votre architecture, bien souvent :

      $ make bzImage

      Installez ensuite votre noyau suivant la procédure adaptée à votre distribution.
    4. Déchargez si nécessaire le module loop.o, recompilez et installez les modules (suivez la procédure de votre distribution si possible) :

      $ make modules
      # make modules_install

      et pensez à rebooter votre système si vous avez changé de noyau.
    5. Finalement (re)chargez loop.o, puis cryptoloop.o.

      # modprobe loop
      # modprobe cryptoloop

      Si le chargement échoue, recommencez à l'étape 3. Si cela ne marche toujours pas, attendez la prochaine version de ce guide.

    Les outils

    Pour manipuler le loop device patché, il faut une version adéquate de lomount. Cet outil, que l'on trouve généralement dans le répertoire /sbin, fait partie des util-linux. Comme précis& précédemment, la version 2.12 intègre un support de la cryptoloop, mais ne fournit pas tous les services que la version 2.11z avec le patch Jari.

    Si actuellement vous n'avez pas les util-linux 2.12 :

    1. Décompactez les sources d'util-linux, soit 2.12 soit 2.11z

      $ tar xzf util-linux-<version>.tar.gz

    2. déplacez-vous dans le répertoire fraîchement créé

      cd util-linux-<version>

    3. Si vous décidez d'utiliser la version 2.11z avec le patch de Jari, appliquez le patch :

      $ bzcat util-linux-2.11z-crypto-v2.diff.bz2 | patch -p1 -E

    4. Configuration et compilation :

      $ ./configure
      $ cd lib; make ; cd ../mount; make

    5. Copiez ensuite mount, umount dans /usr/local/bin, losetup dans /usr/local/sbin. Vous pouvez aussi écraser les fichiers originaux dans /bin et /sbin, mais ce n'est certainement pas ce que souhaite votre distribution.

      # cp mount umount /usr/local/bin/
      # cp losetup /usr/local/sbin/

    Création et montage

    Nous allons préparer un système de fichiers crypté pour un utilisateur en particulier. Le système de fichier sera monté dans le répertoire home de cet utilisateur.

    On pourra aussi utiliser une autre arborescence reprenant la même structure que /home mais dédiée aux données cryptées : /crypt/user/ contenant le container crypté et le système de fichiers crypté pour chaque utilisateur. Ce choix est laissé au soin du lecteur.

    Voici la liste des commandes à utiliser lors la création de votre container crypté :

    $ signifie que la commande est lancée en tant qu'utilisateur lambda, # signifie que la commande requiert les droits du super utilisateur (root).

    Définition des variables d'environnement :

    On définit les chemins et les paramètres de cryptage. On spécifie le nom du fichier qui va contenir le système de fichiers crypté. Ce fichier est appelé par la suite container.

    -- choix d'un périphérique loop disponible, entre 0 et 7
    -- si vous utilisez devfs, vous pouvez utilisez /dev/loop/X
    $ LOOP=/dev/loop0
    -- point de montage du système de fichiers crypté
    -- c'est aussi dans ce répertoire que l'on va placer le container
    $ MOUNTPOINT=$HOME/crypt
    -- nom du fichier crypté contenant le système de fichiers
    $ CONTAINER=$MOUNTPOINT/.crypt.img
    -- algorithme utilisé : AES(rijndael), le vainqueur du concours du NIST
    $ CYPHER=aes
    -- lecture de l'offset dans le fichier
    -- utilisé en plus du mot de passe, peut sécuriser encore plus le container
    -- l'offset est calculé en nombre de secteur pour satisfaire une contrainte
    -- de la cryptoloop : les cyphers travaillent par bloc et non pas par flux.
    $ read sector
    $ OFFSET=$(($sector*512))
    -- taille du container en Mo
    $ read SIZE

    Création du container :

    -- création du container crypté
    -- il est rempli de données pseudo-aléatoires afin de compliquer
    -- les attaques par force brute
    -- (surtout ne pas utiliser /dev/zero pour remplir le container crypté)
    $ mkdir -p $MOUNTPOINT
    $ dd if=/dev/urandom of=$CONTAINER bs=1M count=$SIZE
    $ chmod 600 $CONTAINER

    Activation :

    C'est à ce moment que le système va vous demander de choisir un mot de passe.

    Note : Avec les util-linux 2.12, il est impossible de choisir la taille de la clé, fixée à 256 bits (32 octets). De plus le mot de passe n'est pas étendu/hashé, donc utilisez un mot de passe d'une taille avoisinant les 32 caractères.

    -- chargement des modules
    # modprobe loop
    # modprobe cryptoloop
    # modprobe aes

    -- activation de la cryptoloop, saisie du mot de passe
    # /usr/local/sbin/losetup -e $CYPHER -o $OFFSET $LOOP $CONTAINER

    -- affichage des informations sur le loop device configuré
    # /usr/local/sbin/losetup $LOOP

    Initialisation :

    Création du système de fichier, on utilise ici ext3fs, la version journalisée du système de fichiers ext2fs. Cela a pour avantage de limiter les risques de corruption des méta données dans le container, mais c'est coûteux en ressources si le système de fichiers où se trouve le container est lui aussi journalisé.

    -- création d'un système de fichiers utilisable
    -- à 100% par les utilisateurs normaux, non privilégiés.
    # mkfs.ext3 -j -m 0 -L "home-crypt" $LOOP

    -- montage de ce système de fichiers
    -- ATTENTION : le container crypté devient inaccessible
    -- pour le commun des mortels
    # mount -t ext3 $LOOP $MOUNTPOINT

    -- on donne les droits à l'utilisateur
    # chown <user> :<group> $MOUNTPOINT

    -- l'utilisateur sécurise l'accès à son système de fichiers crypté
    $ chmod 700 $MOUNTPOINT

    -- démontage
    # umount $MOUNTPOINT

    -- suppression du device
    -- note : n'importe quel losetup fera l'affaire ici
    # losetup -d $LOOP

    Si la création du système de fichiers échoue à cause d'une écriture en dehors du périphérique, c'est que vous faites usage de l'offset avec une version de la loop device qui ne le gère pas correctement. Dans ce cas vous pouvez changer de patch ou alors calculer le nombre de blocs disponibles pour le système de fichiers et passer cette valeur à mkfs.ext3 : (taille du container / 512) - offset .

    Au final :

    Maintenant que tout est prêt, on peut monter le container de façon intégré en une seule opération :

    -- ensuite, activation de la loop et montage, en une seule commande
    # /usr/local/bin/mount -t ext3 -o defaults,user,exec,loop,encryption=$CYPHER,offset=$OFFSET $CONTAINER $MOUNTPOINT

    -- et démontage si nécessaire
    # /usr/local/bin/umount $MOUNTPOINT

    Malheureusement, seul root a la possibilité de monter le container crypté. Dans /etc/fstab, une option user=xxx ou group=xxx autorisant seulement un utilisateur ou un groupe d'utilisateur à monter/démonter un système de fichier serait intéressante ici : une idée à creuser.

    Pour l'instant, l'administrateur peut créer un script contenant toutes les commandes nécessaires, et autoriser l'utilisateur à exécuter ce script grâce à 'sudo'.

    NOTE : attention, ici on monte le container crypté par dessus le répertoire le contenant. Quand il est monté, cela rend son accès impossible pour l'utilisateur lambda. Cela évite que l'on puisse effectuer une recherche de clé de cryptage par force brute en comparant le système de fichier décrypté et le container crypté. Mais cette astuce permet surtout d'éviter de modifier le container pendant qu'il est monté.

    Changement de clé, d'algorithme, etc

    Vous serez probablement amenés à changer de mot de passe ou d'algorithme de cryptage. L'opération n'est pas transparente : elle nécessite la création d'un nouveau container et la recopie des informations contenues dans l'ancien.

    Deux solutions sont disponibles : la copie brute du container ou la copie des fichiers.

    Copie brute

    Ici on effectue une copie bloc pour bloc des loop devices :

    -- Déplacement de l'ancien container
    $ mv $CONTAINER ${CONTAINER}.old
    -- Création du nouveau container au minimum de la même taille que l'ancien
    -- en sachant qu'une taille supérieure ne sera pas directement utilisée
    -- Attention aussi au changement d'offset : un offset plus grand implique
    -- une taille plus importante.
    $ dd if=/dev/urandom of=$CONTAINER bs=1M count=<size>
    -- configuration du loop device pour le nouveau container
    # /usr/local/sbin/losetup -e <NEWCYPHER> [-o <NEWOFFSET>] $LOOP $CONTAINER
    -- configuration du loop device pour l'ancien container
    # /usr/local/sbin/losetup -e <OLDCYPHER> [-o <OLDOFFSET>] /dev/loop1 ${CONTAINER}.old
    -- recopie des données
    # dd if=/dev/loop1 of=$LOOP bs=1M
    -- Vérifiez que vos données sont bien présentes
    # mount $LOOP $MOUNTPOINT
    -- Suppression de l'ancien container
    # losetup -d /dev/loop1
    $ rm ${CONTAINER}.old

    Il est possible de spécifier une taille plus grande, de copier les données avec dd, et ensuite d'utiliser un outil comme resize2fs pour agrandir le système de fichiers. Cet exercice est laissé au soin des lecteurs aventureux.

    Copie de fichiers

    Cette fois, nous allons copier les fichiers présents dans le container :

    -- Déplacement de l'ancien container
    $ mv $CONTAINER ${CONTAINER}.old

    Ensuite il faut créer un nouveau container en suivant la même marche à suivre qu'au début. Ce nouveau container doit être suffisament grand pour contenir un système de fichiers contenant les fichiers de l'ancien container. De plus, la remarque précédente au sujet des offsets s'applique ici aussi.

    Avant de monter le nouveau container, activez l'ancien :

    -- configuration du loop device pour l'ancien container
    # losetup -e <OLDCYPHER> [-o <OLDOFFSET>] /dev/loop/1 ${CONTAINER}.old

    Montez ensuite le nouveau container et l'ancien :

    # mount $LOOP $MOUNTPOINT
    -- montage de l'ancien container dans un répertoire temporaire
    # mount /dev/loop1 <tmp_mountpoint>

    Recopiez ensuite les fichiers :

    -- recopie des fichiers
    $ cd <tmp_mountpoint>
    $ cp -Rdp .??* * $MOUNTPOINT/
    $ cd ..

    Supprimez ensuite l'ancien container :

    -- suppression de l'ancien container
    # umount <tmp_mountpoint>
    # losetup -d /dev/loop1
    # umount $MOUNTPOINT
    $ rm ${CONTAINER}.old

    La deuxième solution permet un changement de type de système de fichiers et un redimensionnement simple du système de fichiers, mais nécessite de monter deux fois le container, exposant deux fois les données non cryptées.

    Présentation succinte de Loop-AES

    Loop-AES développée par Jari Ruusu, n'est pas une API de cryptographie générique, ce patch ne fournit que les services de cryptage de volumes. Loop-AES offre plus d'algorithmes que son nom ne le laisse croire : twofish, blowfish, mars et rc6 sont supportés en plus d'AES. Cette solution de cryptage est moins générique mais plus performante que les autres de par sa spécialisation.

    Quelques remarques concernant la sécurité

    Quelques rappels sur la sécurité...

    1. Soyez paranoïaque.
    2. Vérifiez que les personnes qui vous parlent de cryptographie ne sont pas des petits malins qui cherchent à vous induire en erreur.
    3. Utilisez GnuPG et/ou MD5 pour vérifier les signatures de toutes les sources et patches que vous utilisez.
    4. à l'intérieur du système de fichiers crypté, ne pas crypter des fichiers avec le même algorithme et le même mot de passe : ces fichiers risqueraient d'apparaitre en clair$ dans le container. On fait usage d'algorithme de cryptage symétrique, la même clé est utilisée pour crypter et décrypter, et bien souvent la même fonction assure le cryptage et le décryptage : on crypte une fois pour obtenir l'information cryptée, on recrypte une deuxième fois pour obtenir l'information en clair.
    5. Ne pas exporter votre container ni votre système de fichiers crypté : NFS, FTP, Samba, etc... sont à proscrire. Quel intéret de crypter vos données si vous les faites circuler en clair. Utilisez des protocoles sécurisés (SSH, VPN) pour transmettre vos fichiers, cryptés eux-mêmes si besoin.
    6. Protégez votre ordinateur :
    1. Ne stockez vos mots de passe que dans votre tête.
    2. Et ne croyez pas qu'en sachant tout cela vous êtes en sécurité.

    Conclusion

    Nous avons vu comment crypter un système de fichiers contenu dans un fichier. Pour allez plus loin, on peut utiliser une partition en lieu et place du fichier container.

    Il est maintenant 'facile' de crypter ses données avec le noyau Linux, même s'il faut toujours un patch pour la version 2.4. À terme, la version 2.6 de linux plus les util-linux 2.12 offriront à tout un chacun la possibilité de crypter des systèmes de fichiers.

    Ensuite à chacun de voir s'il a besoin de crypter ses données et s'il a confiance dans les algorithmes du kernel.

    Liens

    Copyright

    Copyright (C) 2003 Yann Droneaud Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

    Haut


    Une solution de groupware OpenSource

    Par Anne

    Quand l'évolution des technologies impacte sur l'organisation d'entreprise

    Le schéma organisationnel des entreprises qui était plutôt de type hiérarchique et rigide il y a quelques années tend à  s'aplatir et se doter de nombreuses fonctionnalités transversales.

    Cette évolution implique donc un remaniement des modes de communication et d'organisation, ainsi que du système d'information. Un des outils clé de ce changement est le groupware qui dote l'entreprise de moyens simples et efficaces pour permettre à  l'ensemble de ses collaborateurs d'y parvenir : partage de l'information à  travers de multiples calendriers privés ou non, de forums, d' outils collaboratifs (de type wiki), de gestionnaire de contacts...

    Les quatre membres fondateurs d'eGroupWare sont issus du projet phpGroupWare. Celui-ci n'évoluant pas selon eux dans la bonne direction et ne collant pas assez aux besoins exprimés par les utilisateurs d'un groupware, ils décidèrent de forker(partir et refaire) le projet et d'initier ainsi eGroupWare.

    L'objectif clairement annoncé est de concurrencer des solutions commerciales comme Notes et Exchange tout en respectant les principes de l'Open Source. à€ cet effet l'équipe d'eGroupWare a donc orienté son outil en fonction de ce que doit apporter un logiciel de groupware dans une entreprise, une association,...

    Selon Reiner Jung, chef de projet eGroupWare : "Souvent les gens définissent le groupware comme un regroupement de fonctions comme le mail, une todo liste, des notes et un calendrier. à‡a n'est pas notre définition. Un groupware devrait offrir un espace de travail partagé. Cet espace doit mettre à  disposition un ensemble de modules pour le travail de tous les jours. Dans mon activité quotidienne, je partage aussi des fichiers, gère mes projets, les développeurs ont besoin d'un wiki, d'un forum pour les discussions... Quand je peux exécuter la plupart de mes tâches quotidiennes à  travers un groupware, alors c'en est un véritablement. Nous sommes sur la voie de ce genre de réalisation."

    Dans de nombreux projets, les développeurs et/ou les entreprises créent un road map et décident des besoins des utilisateurs à  la version suivante. à‡a n'est pas la bonne façon de procéder. Nous voulons obtenir un groupware qui remplisse les besoins d'utilisateurs dans le monde professionnel. Selon moi, ce sont les utilisateurs qui développent eGroupWare. Ils ont souvent des connaissances plus importantes que nous sur le fonctionnement d'un groupware et savent pertinemment ce dont ils ont besoin. Le projet doit réaliser, coordonner les demandes, s'assurer de sa viabilité, sa stabilité et sa sécurité."

    Particularité de fonctionnement : le groupe propose à  des entreprises qui souhaitent voir une ou plusieurs fonctionnalités aboutir plus rapidement de financer des heures de développement.. La méthode est de plus en plus courante et gage d'adéquation du développement aux besoins réels.

    Un des avantages d'eGroupWare est sa simplicité de mise en place. Elle ne doit toutefois pas occulter la complexité que représente la mise à  plat du circuit de l'information dans une organisation. En effet, le groupware ne sera finalement que le reflet de ce schéma organisationnel. L'objet de cet article est de montrer pas à  pas la solution technique. Nous n'aborderons pas l'étape préalable indispensable qui consiste à  partir de l'organigramme de l'entreprise pour mettre en place des groupes d'utilisateurs et organiser les différents niveaux d'accès à  l'information.

    eGroupWare est constitué d'un ensemble de modules présentant les fonctionnalités suivantes :

  • webmail
  • carnet de contacts
  • calendrier partagé
  • forum
  • wiki
  • CMS
  • gestion de tickets d'incident
  • éditeur de site wysiwyg
  • lient FTP et gestionnaire de fichiers
  • messagerie instantanée
  • gestionnaire de projets
  • outil de sondage
  • gestion graphique des utilisateurs et groupes, ainsi que de leur compte mail et LDAP
  • Chacun de ces modules, on le verra, peut être partagé avec tout ou partie des utilisateurs accédant à  eGroupWare. Passons aux choses concrètes : les prérequis

    Passons maintenant à  l'installation de la plate-forme qui va supporter eGroupWare. Nous avons fait le choix d'une Mandrake 10.0 pour supporter cette plate-forme.

    Installer une plate-forme LAMP

    L'application nécessite au moins un serveur web, PHP et une base de données. Il est possible de l'installer sur IIS, mais pour une raison on ne peut plus partisane, nous choisirons Apache sur Linux. L'ensemble des informations du groupware et notamment le système d'ACL (Access control List) est stocké dans une base de donnée, qui peut être MySQL ou PostgreSQL.

    Nous allons décrire ci-dessous les modalités d'installation de cette plate-forme LAMP (Linux, Apache, MySQL, PHP).

    La première étape consiste à  installer Apache :

    # urpmi apache2
    Pour satisfaire les dépendances, les paquetages suivants vont être installés (1 Mo):
    apache-conf-2.0.48-2mdk.i586
    apache2-2.0.48-6mdk.i586
    apache2-common-2.0.48-6mdk.i586
    apache2-modules-2.0.48-6mdk.i586
    Est-ce correct ? (O/n)
    Préparation...              ##################################################
       1:apache-conf            ##################################################
       2:apache2-modules        ##################################################
       3:apache2-common         ##################################################
       4:apache2                ##################################################

    Le fichier de configuration est /etc/httpd/conf/httpd.conf. (Mandrake a délocalisé une partie de ce fichier dans /etc/httpd/conf/commonhttpd.conf). La configuration par défaut permet de lancer dès maintenant le service Apache :

    # service httpd start
    Starting httpd:                                                 [  OK  ]

    La plate-forme nécessite également l'installation de PHP :

    # urpmi php
    Un des paquetages suivants est nécessaire :
     1- apache2-mod_php-2.0.48_4.3.4-1mdk.i586
     2- mod_php-4.3.4-1mdk.i586
     3- php-cli-4.3.4-4mdk.i586
     4- php-cgi-4.3.4-4mdk.i586
    Que choisissez-vous ? (1-4)1
    Préparation...              ##################################################
       1:apache2-mod_php        ##################################################
    Shutting down httpd2: [  OK  ]
    Checking configuration sanity for Apache 2.0:  [  OK  ]
    Starting httpd2: [  OK  ]

    Là  encore la configuration proposée permet un fonctionnement immédiat de PHP. Il nous reste enfin à  installer le serveur MySQL :

    # urpmi mysql
    Un des paquetages suivants est nécessaire :
     1- MySQL-4.0.18-1.1.100mdk.i586
     2- MySQL-Max-4.0.18-1.1.100mdk.i586
    Que choisissez-vous ? (1-2)1
    Pour satisfaire les dépendances, les paquetages suivants vont être installés (18 Mo):
    MySQL-4.0.18-1.1.100mdk.i586
    MySQL-client-4.0.18-1.1.100mdk.i586
    MySQL-common-4.0.18-1.1.100mdk.i586
    libmysql12-4.0.18-1.1.100mdk.i586
    perl-Mysql-1.22_19-9mdk.i586
    Est-ce correct ? (O/n)
    Préparation...              ##################################################
       1:libmysql12             ##################################################
       2:MySQL-client           ##################################################
       3:perl-Mysql             ##################################################
       4:MySQL-common           ##################################################
       5:MySQL                  ##################################################
    040512 12:40:46  /usr/sbin/mysqld: Shutdown Complete

    On procède ensuite au démarrage du service :

    # service mysql start
    Starting mysql:                                                 [  OK  ]

    L'installation nécessite enfin un certain nombre de modules pour Apache, nécessaires au bon fonctionnement d'eGroupWare.

    # urpmi php-mysql php-xml php-imap php-ldap
    Préparation...              ##################################################
       1:php-imap               ##################################################
       2:php-xml                ##################################################
       3:php-mysql              ##################################################
       4:php-ldap               ##################################################

    Voilà  votre plate-forme prête à  fonctionner !

    L'annuaire LDAP

    Il est également possible d'adosser le groupware à  un annuaire LDAP (site officiel : http://openldap.org). Avantage de la méthode : il va permettre de centraliser . C'est l'option qui sera présentée ici car elle permet d'utiliser de manière optimale les fonctionnalités d'eGroupWare. L'installation du serveur LDAP est simple :

    # urpmi openldap-servers openldap-client
    Préparation...              ##################################################
       1:openldap-servers       ##################################################
       2:openldap-client        ##################################################

    Le recours à  un annuaire LDAP présuppose deux choses : l'installation du module php-ldap pour Apache (ce que nous avons fait dans le paragraphe précédent) et l'intégration d'une classe nécessaire pour inclure des paramètres eGroupWare dans la définition des comptes de groupes et d'utilisateurs. Pour ce faire, copiez les schémas fournis dans les sources (les schémas seront ajoutés dès la prochaine version du RPM Mandrake), phpgwaccount.schema et phpgwcontact.schema dans l'arborescence LDAP. Comme leurs noms l'indiquent, l'un permet de définir les comptes de groupes et d'utilisateurs, l'autre permet de définir le stockage des contacts dans l'annuaire. Pour finir, déclarez l'utilisation de ces schémas dans slapd.conf et redémarrez le serveur.

    # ls /etc/openldap/schema
    local.schema phpgwaccount.schema phpgwcontact.schema
    # cat /etc/openldap/slapd.conf
    ...
    include /etc/openldap/schema/phpgwaccount.schema
    include /etc/openldap/schema/phpgwcontact.schema
    ...
    # service ldap restart

    Le support de la messagerie

    Nous allons utiliser également un serveur SMTP et un serveur POP/IMAP. Les choix réalisés par l'équipe d'eGroupWare privilégient Postfix d'un côté et Cyrus-IMAP de l'autre. Il est tout à  fait envisageable d'utiliser d'autres produits mais ceux-ci ont l'avantage de permettre ensuite la gestion du compte de messagerie à  travers l'interface du groupware (gestion des boites mail, alias de mail, forwards, et bientôt les absences).

    Attention : les requêtes sur les utilisateurs eGroupWare concernant la messagerie se basent sur la classe qmailUser et l'attribut mailAlternateAddress. Ci-dessous un extrait du fichier de configuration de Postfix main.cf concernant la construction de la requête LDAP à  effectuer :

    # cat /etc/postfix/main.cf

    virtual_alias_maps = ldap:ldapuser, ldap:ldapgroup

    ldapuser_server_host = 127.0.0.1
    ldapuser_server_port = 389
    ldapuser_bind = yes
    ldapuser_bind_dn = cn=adminmail,dc=domain,dc=com
    ldapuser_bind_pw = Xd25./T
    ldapuser_search_base = ou=Personnes,dc=domain,dc=com
    ldapuser_timeout = 60
    ldapuser_query_filter = (&(objectclass=qmailUser)(mailAlternateAddress=%s))
    ldapuser_result_attribute = mail
    ldapuser_lookup_timeout = 60

    ldapgroup_server_host = 127.0.0.1
    ldapgroup_server_port = 389
    ldapgroup_bind = yes
    ldapgroup_bind_dn = cn=adminmail,dc=domain,dc=com
    ldapgroup_bind_pw = Xd25./T
    ldapgroup_search_base = ou=Groupes,dc=domain,dc=com
    ldapgroup_timeout = 60
    ldapgroup_query_filter = (&(objectclass=mailRecipient)(mailAlternateAddress=%s))
    ldapgroup_result_attribute = rfc822MailMember
    ldapgroup_lookup_timeout = 60
    ....

    On pourra bien sur affiner cette configuration mais ce n'est pas l'objet de l'article. Consulter Postfix-Cyrus-Web-cyradm-HOWTO, un bon point de départ.

    L'installation de eGroupWare

    Les étapes de l'installation

    L'installation peut se faire à  partir des sources :

    # cd /var/www/html
    # tar xjf eGroupWare-0.9.99.015-1.tar.bz2

    Comme nous travaillons sur une Mandrake, nous utiliserons les packages prévu à  cet effet. Il est possible de télécharger le package édité par l'équipe d'eGoupWare (eGroupWare-all-apps-0.9.99.015-1.noarch.rpm). Toutefois dans un soucis de cohérence, nous utiliserons les packages fournis par la source contrib de Mandrake. Pour installer eGroupWare et tous ses modules :

    # urpmi -a egroupware egroupware-

    Par défaut les fichiers s'installent dans /var/www/html/egroupware.

    Le processus d'installation d'eGroupWare prévoit la création de la base de donnée pour MySQL et PostgreSQL. Nous reprenons ci-dessous les étapes qui permettent la création en ligne de commande de la base et d'un utilisateur qui aura les droits sur cette base pour MySQL.

    # mysqladmin --user=root create egroupware
    # mysql --user=root mysql
    mysql> GRANT ALL ON egroupware.* TO egroupware@localhost IDENTIFIED BY 'passwd';
    mysql> flush privileges;

    Voilà , nous laissons de côté maintenant la ligne de commande pour passer à  l'installeur web d'eGroupWare. L'installation va alors se faire en 3 étapes à  partir de l'URL suivante dans notre cas : http://localhost/egroupware/setup.

    Vérification de l'installation

    La première étape va vous permettre de vérifier qu'il ne vous manque aucun composant pour le bon déroulement de la suite de l'installation. Elle vérifie notamment les permissions sur les fichiers et la présence des extensions pour la base de données utilisée. Nous verrons par la suite les options liées à  la configuration de PHP. Aucune n'est bloquante mais certaines sont importantes pour la sécurisation du groupware.

    Génération du fichier header.inc.php

    Ce fichier contient les paramètres de base d'eGroupWare comme les paramètres de connexion à  la base de données mais aussi la possibilité d'en générer plusieurs instances en définissant des domaines. Cette notion peut être utile si l'on souhaite par exemple définir deux interfaces distinctes d'eGroupWare, par exemple, l'Intranet et les clients.

    Vous allez également créer deux utilisateurs clés : l'un vous servira à  rééditer cette page, l'autre à  poursuivre la procédure d'installation.

    Il est recommandé de conserver une sauvegarde de ce fichier.

    Installation des applications

    Connectez-vous comme demandé.

    L'étape suivante consiste à  valider l'installation des différents applications du groupware et créer les tables correspondantes dans votre base de données.

    Configuration d'eGroupWare

    La configuration se présente ensuite comme une série de champs à  renseigner. L'installation d'eGroupWare nécessite la création d'un répertoire, de préférence hors de l'arborescence Apache qui contiendra notamment les fichiers uploadés par l'intermédiaire du gestionnaire de fichiers. Ce répertoire devra être accessible à  l'utilisateur exécutant l'instance Apache.

    # mkdir /var/lib/egroupware
    # chown -R apache:apache /var/lib/egroupware

    Vous devrez également spécifier l'IP ou le nom de votre serveur FTP si vous souhaitez utiliser le module FTP du groupware.

    Nous voilà  maintenant arrivés à  la configuration de l'authentification et des comptes utilisateurs. Plusieurs options s'offrent à  vous. Si vous ne disposez pas d'annuaire LDAP, choisissez de stocker les comptes dans la base de données. Dans notre cas, ayant recours à  LDAP, nous allons donc compléter les éléments nécessaires. Ils sont classiques pour ceux qui ont l'habitude de manipuler ce service : home directory à  utiliser, shell, contexte des OU (Organizational Units) d'utilisateurs et de groupes, manager de LDAP et mot de passe.

    Il est indispensable également d'autoriser l'utilisation de LDAP v.3, que l'on retrouve par défaut dans la majorité des distributions. Enregistrer la configuration obtenue.

    Nous compléterons cette phase par la création d'un compte administrateur qui sera utilisé ensuite pour l'administration du groupware (gestion des ACL, gestion des utilisateurs et des applications). Il vous est d'ailleurs proposé de créer des comptes de démonstration pour tester le bon fonctionnement de l'application. Vous pouvez en vérifier la création dans l'annuaire :

    # ldapsearch -x "uid=adminegw"
    # adminegw, Users, domain, com
    dn: uid=adminegw,ou=Users,dc=domain,dc=com
    phpgwAccountType: u
    uidNumber: 2008
    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: inetOrgPerson
    objectClass: posixAccount
    objectClass: shadowAccount
    objectClass: phpgwAccount
    cn: adminegw adminegw
    uid: adminegw
    sn: adminegw
    givenName: adminegw
    homeDirectory: /home/adminegw
    loginShell: /bin/false
    gidNumber: 2
    phpgwAccountStatus: A
    phpgwAccountExpires: -1

    L'utilisateur est bien créé et on retrouve la classe phpgwAccount ainsi que les attributs élémentaires : phpgwAccountType (u : user ou g : groupe), phpgwAccountStatus (A : compte actif), phpgwAccountExpires (-1 : jamais).

    La configuration est maintenant terminée. Vous pouvez toutefois à  ce stade gérer les langues (ajouter / supprimer). 22 langues sont aujourd'hui disponibles, par défaut sont sélectionnés l'anglais et le français. Vous pouvez également gérer les applications. Le mode d'installation que nous avons utilisé fournit toutes les applications disponibles, vous pouvez restreindre cette liste.

    L'installation et la configuration de base sont maintenant terminées, nous passons à  la configuration de l'utilisation du groupware.

    Configuration du groupware

    Une fois connecté en tant qu'administrateur du groupware, allez sur le paneau d'administration .

    Il vous offre les fonctionnalités suivantes :

  • gestion des applications
  • gestion des utilisateurs
  • configuration du site et paramétrage mail
  • gestion des catégories et ACL
  • Avant de poursuivre il est indispensable de définir ces 2 dernières notions qui sous-tendent toute la configuration qui va suivre.

    ACL et catégories globales

    Les ACL sont un terme générique (Acces Control List) que l'on retrouvera dans de nombreuses applications. Elles vont définir les droits d'accès d'un utilisateur et/ou d'un groupe aux données d'une application. Elles sont au nombre de quatre : lecture, ajout, modification, suppression.

    Dans notre exemple, les membres du groupe commerciaux auront tous les droits sur les données du gestionnaire de fichiers relatives à  leur groupe. Seuls les membres du groupe techniciens auront un accès en lecture.


    Les catégories globales permettent d'organiser les données et sont communes à  toutes les applications. Il est possible également de créer des catégories spécifiques à  une application ainsi que des catégories personnelles. Elles sont importantes car elles permettent de rationaliser l'affichage des données et de d'organiser celles-ci plus clairement.

    Une administration centralisée des utilisateurs

    La gestion des utilisateurs et des groupes peut se faire à  plusieurs niveaux :

  • le module de gestion de comptes utilisateurs : il permet de créer, modifier, supprimer un utilisateur. Les modifications portent sur les données de base du compte, la configuration mail, les applications attribuées spécifiquement à  un utilisateur.
  • le module de gestion de comptes de groupes : il permet de positionner les utilisateurs dans le groupe choisi. Pour pouvoir positionner les ACL, cliquer sur l'application et sauvegarder puis cliquer à  nouveau sur la puce situé à  droite de la dite application.
    On conseille souvent d'utiliser un groupe "Default" dans lequel on positionnera tous les utilisateurs. Celui-ci permettra de fixer les applications de base communes à  tous ainsi que des ACL. On affinera ensuite groupe par groupe ces ACL en fonction des besoins.
  • On trouve enfin la gestion des préférences utilisateurs. Ces préférences agissent sur l'ergonomie des applications, leur mode de visualisation, la possibilité ou non de personnaliser la configuration. Ces préférences peuvent être définies par les utilisateurs eux-mêmes mais restreintes par l'administrateur qui positionnera des préférences forcées pour une ou plusieurs applications. Enfin on dispose également de la possibilité de fixer des préférences par défaut.
  • Revue de détail des principales applications

    Nous allons ici passer en revue les applications les plus courantes ainsi que leurs fonctionnalités dans le cadre du groupware.

  • Messagerie

    eGroupWare propose deux types de webmails qui offrent les fonctionnalités classiques de ce type de client. On trouve entre autres un lien avec le carnet de carnet d'adresses.
  • Carnet d'adresses
    Il s'agit la d'une fonctionnalité classique. Il permet des importations et des exportations à  partir de différents formats standards. L'ensemble des contacts est stockable dans une base LDAP.
  • Calendrier

    Le calendrier dispose de vues quotidienne, par semaine, mensuelle ou annuelle. On peut ajouter des événements pour soi-même, d'autres utilisateurs ou des groupes. Il est possible alors de générer des alarmes par mail pour prévenir les différents participants. Ce calendrier est également doté d'un système de confirmation pour chaque événement qui permet ainsi au mieux leur planification.
  • Egalement à  disposition, un planificateur de tâches, qui permet de visualiser rapidement les plages horaires disponibles pour fixer un rendez-vous pour une ou plusieurs personnes.

  • Infolog
    C'est un outil à  mi chemin entre le post-it© et la mini gestion de projet. Il permet de programmer des tâches, en associant ou non d'autres participants, des contacts, des événements du calendrier, des fichiers. Des indicateurs permettent ensuite de visualiser la progression du dit projet.
  • L'application propose en tout une quinzaine de modules.

    Sécurisation et optimisation de l'installation

    La sécurisation de la plate-forme supportant eGroupWare relève des conseils habituels liés à  l'administration d'une plate-forme LAMP (Linux-Apache-MySQL-PHP).

    Concernant le serveur MySQL, vérifiez que l'utilisateur root dispose bien d'un mot de passe. En effet, à  l'installation du serveur, l'utilisateur root est initialisé dans la base " mysql" sans aucun mot de passe :

    # mysqladmin -u root password 'mot_de_passe'

    De plus nous allons restreindre l'accès au serveur MySQL aux seules requêtes lancées en local :

    # cat /etc/my.cnf
    [mysqld]
    ...
    bind_address = 127.0.0.1
    ...

    Concernant la configuration de PHP, les développeurs apportent quelques conseils pour en optimiser les performances :

    max_execution_time ? 30
    memory_limit ? 16 Mo
    register_globals = Off
    safe_mode = On

    Vous devrez également personnaliser le paramètre "upload_max_filesize" en fonction des besoins pour le gestionnaire de fichiers. C'est à  ce niveau que la taille des uploads de fichiers de cette application sera limité et non par un paramètre propre au groupware.

    Enfin eGroupWare peut gagner considérablement en rapidité d'exécution grâce à  Turck MMCache. Il accélère l'interprétation du code PHP et réduit la charge du serveur.

    # urpmi php-mmcache php-mmcache-admin
    installation de php-mmcache php-mmcache-admin
       1:php-mmcache            ##################################################
       2:php-mmcache-admin      ##################################################

    Attribuer un mot de passe à  l'administrateur de l'interface de gestion du cache :

    # php -q /var/www/html/admin/php-mmcache/mmcache_password.php
    Changing password for Turck MMCache Web Interface (mmcache.php)

    Enter admin name: admincache
    New admin password: R3./po
    Retype new admin password: R3./po

    Add the following lines into your php.ini and restart HTTPD

    mmcache.admin.name="admincache"
    mmcache.admin.password="$1$BGhHjZ5A$wNPAxc3BfU12POJoxopBO/"

    On accède ensuite à  l'interface de gestion du cache : http://localhost/admin/php-mmcache

    eGroupWare, les projets

    Le projet est aujourd'hui disponible dans sa première version stable. Mais le groupe de développement travaille déjà  sur ce que sera la prochaine version stable, la 1.2. Dans cette optique, de nombreux d'objectifs ont étés fixés et mis en avant.

    Il est projeté de mettre à  disposition un moteur de workflow1

    Dans les développements très attendus, on note aussi un certain nombre de connecteurs vers l'extérieur qui permettront d'inclure encore plus le groupware dans son environnement : une synchronisation avec les PDA (ou organiseurs personnels en bon français) disponible très prochainement, un connecteur pour Evolution, et un connecteur pour Outlook.

    Il est prévu également de travailler sur l'ergonomie de l'interface utilisateur et notamment un assistant pour la configuration de celle ci. De nouveaux modèles de documents, ainsi que de nouvelles fonctionnalités comme le glisser-déposer sont également au programme.

    Des applications vont être ré-écrites, soit totalement (carnet d'adresses, gestion des accidents), soit partiellement(webmail, gestionnaire de fichiers, gestion de projets).

    Enfin pour vérifier l'identité de l'utilisateur du groupware, celui-ci devrait inclure également une fonction d'autorité de certification, tout ceci dans un souci de mieux répondre aux exigences de sécurisation du système.

    Liens

  • le site du projet
  • les listes de diffusion (utilisateurs, développeurs)
  • Interview de Reiner JUNG, chef de projet
  • le site d'Apache
  • le site de MySQL
  • le site de OpenLDAP
  • HOWTO plate-forme LAMP
  • HOWTO Postfix/Cyrus-IMAP
  • Haut


    Fin du chapitre