Section Pro de Léa

Transcription

Section Pro de Léa

LéaBook, Chapitre :
Section Pro de Léa
par tous les amis de Léa
Les droits de copies sont détenus par les auteurs des différents articles.
Les droits de copie du livre lui−même sont détenus par Léa (Association Loi de 1901).
Vous êtes autorisé à copier et diffuser ce livre. La vente de ce livre est soumise à l'autorisation des différents auteurs de celui−ci.
Léa pour les pros
Table des matières
Léa pour les pros !...............................................................................................................................................................................................................1
La Haute Disponibilité............................................................................................................................................................................................1
Statut de ce mémo...............................................................................................................................................................................1
Introduction...........................................................................................................................................................................................1
I) La disponibilité des services..............................................................................................................................................................1
II) La disponibilité des données............................................................................................................................................................6
III) De la théorie à la pratique...............................................................................................................................................................9
III) Les exemples concret de haute disponibilité.................................................................................................................................14
Le mot de la fin...................................................................................................................................................................................24
Routeur FLI4L......................................................................................................................................................................................................25
C'est quoi Fli4L ?................................................................................................................................................................................25
Installation..........................................................................................................................................................................................26
Le mot de la fin...................................................................................................................................................................................33
Le LVM (Logical Volume Manager).....................................................................................................................................................................35
De l'utilité du LVM................................................................................................................................................................................................35
Les composants du LVM.....................................................................................................................................................................................35
Utiliser le LVM : ce dont il faut disposer...............................................................................................................................................................36
Kernel et utilitaires...............................................................................................................................................................................36
Sur quels périphériques et systèmes de fichiers puis−je faire du LVM ?............................................................................................37
Configuration du LVM..........................................................................................................................................................................................37
L'arborescence du LVM.......................................................................................................................................................................37
Création d'un volume physique...........................................................................................................................................................37
Création d'un groupe de volume..........................................................................................................................................................38
Création d'un volume logique..............................................................................................................................................................38
Recueillir des informations sur le LVM................................................................................................................................................................39
Commandes complémentaires............................................................................................................................................................................40
Redimensionner un groupe de volumes..............................................................................................................................................40
Redimensionner un volume logique....................................................................................................................................................40
Une fonction particulière du LVM : la réalisation de snapshots...........................................................................................................41
Autres commandes..............................................................................................................................................................................41
Utilisation pratique du LVM dans la gestion de l'espace......................................................................................................................................41
Evolution du LVM : LVM 2...................................................................................................................................................................................42
Le device−mapper...............................................................................................................................................................................42
Utilisation d'un arbre binaire................................................................................................................................................................42
Une plus grande configurabilité...........................................................................................................................................................42
Compatibilité LVM1 / LVM2.................................................................................................................................................................42
Autre....................................................................................................................................................................................................43
En conclusion......................................................................................................................................................................................................43
Liens utiles...........................................................................................................................................................................................................43
QoS/Gestion de la bande passante sous Linux...................................................................................................................................................44
Introduction.........................................................................................................................................................................................44
QoS via iptables.................................................................................................................................................................................44
Gestion de la bande passante sous Linux..........................................................................................................................................44
Script de visualisation des files d'attentes..........................................................................................................................................54
Conclusion..........................................................................................................................................................................................54
Crypter un système de fichiers............................................................................................................................................................................55
Une solution de groupware OpenSource.............................................................................................................................................................61
Quand l'évolution des technologies impacte sur l'organisation d'entreprise.......................................................................................61
Installer une plate−forme LAMP.........................................................................................................................................................61
L'annuaire LDAP.................................................................................................................................................................................62
Le support de la messagerie..............................................................................................................................................................63
L'installation de eGroupWare.............................................................................................................................................................63
Configuration du groupware...............................................................................................................................................................66
Revue de détail des principales applications......................................................................................................................................68
Sécurisation et optimisation de l'installation.......................................................................................................................................69
eGroupWare, les projets.....................................................................................................................................................................69
Liens...................................................................................................................................................................................................70
i
Léa pour les pros !
ii
Cette section contient les chapitres relatifs à une utilisation professionnelle de Linux.
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,
1
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 :
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)
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.
2
I) La disponibilité des serv
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 :
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)
3
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.
4
I) La disponibilité des serv
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
A
A
192.168.10.2
192.168.10.3
192.168.10.4
; Server 1
; Server 2
; 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é.
5
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.
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
Network Block Device (NBD)
NFS
CodaFS
ODR : Online Disk Replicator
ENBD : Enhanced Network Block Device
Network RAID
[MIRRORING]
[MIRRORING]
[SHARED]
[SHARED]
[MIRRORING]
[MIRRORING]
[MIRRORING]
2) Volume Managers
LVM
[PARTITIONING]
EVMS : Enterprise Volume Management System (émulateur lvm)[PARTITIONING]
6
II) La disponibilité des donn
3) FileSystem
GFS
ReiserFS
Ext3
JFS (IBM)
XFS (SGI)
FENRIS (Timponagos)
M2CS (Timponagos)
Intermezzo
LinLogFS
[CLUSTERING/JOURNALING]
[JOURNALING]
[JOURNALING]
[JOURNALING]
[JOURNALING]
[CLUSTERING]
[CLUSTERING]
[CLUSTERING]
[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
X
X
X(a)
X
NFS
X(a)
Coda FS
X
X
Online Disk Replicator (ODR)
X
X
X
X(a)
Enhanced Network Block Device
X
X
X
Network RAID
X
X
X
X
LVM
X
X
X
X
X
Enterprise Volume Management
X
X
X
X
X
X
X
GFS
X
X
ReiserFS
X
X
Ext3
X
X
JFS
X
X
FENRIS
?
?
?
?
?
?
?
M2CS
?
?
?
?
?
?
?
InterMezzo
X
?
X
X
X
LinLogFS
X
X
X
RAID
X
SAN
X(a)
X
(a) Tout dépend du système de fichiers utilisé sur le serveur
X
X
X(?)
X
X
X
X(a)
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.
7
II) La disponibilité des données
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.
8
II) La disponibilité des donn
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
Réseau
Réseau déjà existant
SAN
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
K − CodaFS dans une solution de haute disponibilité
Administration directe incluant l'infrastructure SAN
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.
9
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)
10
III) De la théorie à la prati
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.
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.
11
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.
• Le réseau NAS : il utilise un réseau déjà existant, il n'est donc pas nécessaire d'investir énormement dans une conception réseau pour ce
type de stockage.
Pour des raisons de performance, il est préférable de s'approprier un sous−réseau propre pour NAS. Comme vous l'avez sûrement
remarqué, plusieurs serveurs sont rattachés aux seuls serveurs NAS. Il existe un réel problème de goulot d'étranglement au point 'O'.
• Le réseau SAN : il utilise une connexion SCSI/Fibre Channel. Contrairement à NAS, celui−ci demande plus d'investissement pour concevoir
ce type de stockage.
12
III) De la théorie à la prati
Même si celui est onéreux, le goulot d'étranglement n'existe pas (ou bien il faut réellement en vouloir :)
• Réseau NAS/SAN : ce réseau est une fusion entre le NAS et SAN. Bon attention au schéma, il faut le comprendre :)
13
III) Les exemples concret de haute disponibilité.
Normalement, c'est un peu plus compliqué, car les hubs/switch (non représentés) répartissent les données des serveurs vers les différents SAN qui,
eux−mêmes, répartissent vers les différents Serveur NAS.
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.
14
III) Les exemples concret de haute disp
• Avantage de cette solution : une haute disponiblité correcte pour une mise en place relativement simple.
• Inconvénient de cette solution : des données qui sont uniques entre chaque serveur, risque de perte de données notamment pour les
serveurs de données (ex: smtp)
B. FailOverServices Simples avec réplication locale
Logiciels ou matériels nécessaires : HeartBeat + Raid + services multipliés par le nombre de serveurs.
15
• Avantage de cette solution : la perte de données dûe à la perte d'un disque est résolue.
• Inconvénient de cette solution : tout comme le point FailOverServices Simples (A), les données sont uniques sur chaque serveur. Le fait
d'ajouter des disques en Raid n'apporte pas véritablement d'avantage si ce n'est que les données seront effectivement bien protégées.
C. FailOverServices Simples avec réplication réseau
Logiciels ou matériels nécessaires : HeartBeat + Système de fichier de réplication + les services multipliés par le nombre de serveurs.
16
• Avantage de cette solution : les données sont disponibles directement sur les deux serveurs en local (rapidité)
• Inconvénient de cette solution : très peu, mis à part que la réplication nécessite un bon réseau en support pour synchroniser rapidement et
efficacement les données entre les serveurs.
D. FailOverServices Simples avec utilisation d'un serveur de données
Logiciels ou matériels nécessaires : heartBeat + NFS (ou équivalent) + les services multipliés par le nombre de serveurs−services.
17
• Avantage : les données sont disponibles pour les deux serveurs en direct
• Inconvénient : aucun pour les services. Si le serveur de données tombe, aucun des serveurs n'aura accès aux données.
18
E. FailOverServices Simples avec utilisation d'un serveur de données "FailOveriser" réplication réseau
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.
19
20
• Avantage : les données sont disponibles pour les deux serveurs en direct et en redondance, une disponibilité accrue
• Inconvénient : aucune réplication de données en local, l'un des disques pourrait tomber.
F. FailOverServices Simples avec utilisation d'un serveur de données "FailOveriser" réplication réseau et local
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.
21
22
• Avantage : une grande disponibilité avec quatre serveurs.
• Inconvénient : si les serveurs primaires sont beaucoup solicités, ces derniers ne seront plus disponibles.
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.
• Avantage : une grande disponibilité avec prise de conscience des possibilités de haute sollicitation de groupe primaire de serveurs
• Inconvénient : nécessite une infrastructure solide dûe au nombre de machines. Que se passe−t−il si le routeur tombe ? :)
23
Le mot de la fin
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 :
• InterMezzo et Coda
• Network Block Device
• Global File System HOWTO
• CodaFS
• SAN/NAS
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 ;−)
24
Routeur FLI4L
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
• Création de la disquette du routeur sous Unix, Linux et Windows.
• Configuration à l'aide d'un seul fichier texte (ASCII).
• Support pour IP−Masquerading et Port−Forwarding (NAT et PAT).
• Least−Cost−Routing (LCR) : sélection automatique du fournisseur d'Accès Internet en fonction d'un horaire prédéfini et du coût des
communications.
• Affichage du protocole de la connexion et calcul du coût des communications.
• Client Windows/Unix/Linux imonc inclus (interface vers imond et telmond).
• Upload de nouveaux fichiers via le client Windows, imonc (afin de mettre à jour le routeur).
• Disquette de démarrage en vfat.
• Utilisation possible de disquettes de 1680 ko.
• Filtrage de paquets (Packet filter) : contrôle des accès vers les ports du routeur (firewall).
• Utilisation d'interfaces virtuelles WAN appelées circuits.
• Utilisation possible en parallèle des circuits ADSL et RNIS.
Routeur
• Noyau Linux 2.2.19
• IP−Masquerading + PacketFilter pour la sécurité.
• Serveur DNS afin d'éviter l'accès des PC Windows vers le WAN pour la plupart des requêtes.
• Affichage des informations de connexion (monitoring) et LCR pour le serveur imond.
• Gestion des appels téléphoniques entrants pour le serveur telmond.
Support Ethernet
Gestionnaires pour la plupart des cartes réseau : plus de 40 familles de cartes reconnues.
Support ADSL
• Driver Roaring Penguin PPPoE avec Dial−on−Demand (numérotation à la demande facultative).
• PPTP pour les connexions ADSL en Autriche et Pays−Bas (EXPERIMENTAL).
Support ISDN
• Drivers HiSaX actuels : support pour 37 adaptateurs ISDN.
• Différentes variantes de connexion : in/out/callback, raw−ip/ppp.
• Agrégation de canaux (Multilink PPP) : sélection automatique ou manuelle en fonction de la bande passante.
• Sélection manuelle du second canal via le client Windows/Unix.
• En option : routage IPX.
Applications en option (packages)
• Serveur DNS.
• Serveur DHCP.
• Login SSH.
• Service Telnet et/ou FTP.
• Affichage online/offline simple par LED.
• Programme d'affichage en LCD avec format changeable.
• Console série en option (voir HOWTO).
• Mini−serveur pour ADSL monitoring.
• Module IPSEC, ipsec et pptp.
• Accès restrictif pour des réseaux spécifiques du remote.
• Support PCMCIA (EXPERIMENTAL).
• Protocole des messages sytème: syslogd et klogd.
• Configuration des adaptateurs ISA−PNP: iaspnp tools.
• Utilitaires supplémentaires pour le débogage.
• Configuration du port série.
• Système de secours pour le contrôle distant via ISDN.
• Ecran LCD: affichage des connexions et du flux de données.
• Serveur/routeur PPP via le port série.
• Emulateur ISDN via le port série.
25
C'est quoi Fli4L ?
• Serveur d'impression.
• Accès au serveur de temps pour la synchronisation du réseau.
• Exécution de commandes/procédures quand un appel téléphonique se présente (ex: Internet dial−in).
• Support pour l'IP aliasing (permet d'avoir plus d'une adresse IP par carte réseau).
Hardware
• ISDN : minimal : CPU 386 à 25MHz, recommandé : CPU 486 à 33 MHz.
• ADSL : minimal : 486 CPU − DX2/66, recommandé : CPU 486 DX4/100 à 100 MHz ou CPU Pentium à 75 MHz.
• Mémoire 8MB, recommandé : 16 MB.
• Adaptateur Ethernet (support pour plus de 40 familles d'adaptateurs).
• ISDN : adaptateur ISDN supporté par HiSaX (Type 1−37), AVM−B1 ISA/PCI ou ICN−2B.
• Pas de disque dur, juste un lecteur de disquette.
• Une disquette de démarrage contenant tous les fichiers nécessaires.
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 :
• Cartes réseau D−LINK DFE−530TX
• HUB SMC 3616TC
• Câbles Cat5 non croisées
• Adaptateurs ISDN : Gazel ISA−PNP, ELSA microlink PCI
• Ordinateur faisant fonction temporaire de routeur : Pentium 200 MHz muni d'un lecteur de disquette.
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:
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
26
C'est quoi Fli4L ?
# 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
27
C'est quoi Fli4L ?
#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'
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
28
C'est quoi Fli4L ?
# 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
29
C'est quoi Fli4L ?
# 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'
FIREWALL_DENY_PORT_2='54:112
REJECT'
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='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
30
Installation
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):
31
Installation
#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
# 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='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'
32
Installation
# 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
33
Installation
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.
34
Le LVM (Logical Volume Man
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.
• Chaque disque dur ou partition va être transformé en volume physique. Cette opération consiste à découper le disque en tranches,
appelées Physical Extents (PE). Par défaut (et convention), 1 PE = 4Mo.
• Chaque volume physique va être inséré dans un groupe de volumes. Celui−ci peut contenir un ou plusieurs volumes physiques (donc
disques ou partitions). Un groupe de volume est un espace logique découpé en Logical Extents (LE) de même tailles que les physical
extents, soit 4 Mo par défaut.
Le système va ensuite établir des pointeurs entre un physical extent et un logical extent comme indiqué sur le schéma ci−dessous. (schéma
1)
Schéma 1 : système des pointeurs LVM
• La dernière étape va consister à découper le groupe de volumes en partitions appelées volumes logiques dans lesquelles nous pourrons au
choix, créer un système de fichier, une partition de swap. Ces partitions pourront être redimensionnées et/ou déplacées.
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
35
Utiliser le LVM : ce dont il faut disposer
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 :
• la taille que l'on attribuera à un volume logique s'exprime en nombre de logical extents. Ceux−ci sont indivisibles. Si sa taille est de 4 Mo et
que je souhaite un volume logique de 14 Mo, le système attribuera 4 logical extents au volume logique, soit 16 Mo (arrondi au nombre de LE
supérieur)
• la taille d'un PE, et donc d'un LE, est personnalisable lors de la création d'un volume physique.
• les noms des groupes de volumes et volumes logiques sont personnalisables à leur création
• Attention : la création d'un volume physique écrase toutes les données existantes sur la partition et/ou le disque !!
• L'utilisation du LVM pour partitionner un disque entraine une perte d'espace liée à l'écriture des données nécessaires au système pour gérer
le LVM (métadatas) :
♦ la PVRA : Physical Volume Reserved Area. Comme son nom l'indique, elle contient les informations LVM spécifiques au volume
physique.
♦ la VGRA : Volume Group Reserve Area. Elle contient les informations liées au groupe de volumes mais aussi aux volumes
logiques contenus dans le groupe de volumes
♦ la BBRA : Bad Block Relocation Area : cette zone contient des informations liées au mécanisme de ré−allocation des blocs
défectueux.
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 :
• le kernel
• les commandes nécessaires pour gérer les structures LVM.
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
36
Sur quels périphériques et systèmes de fichiers puis−je
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 « / » (la partition racine de votre systeme). 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
/dev/hdb1
1
730
/dev/hdb2
731
1339
/dev/hdb3
1340
1650
Fin
Blocs
5863693+ 8e
4891792+ 8e
2498107+ 8e
Id Système
Linux LVM
Linux LVM
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
37
Création d'un groupe de volume
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
38
Recueillir des informations sur le
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
VG Access
VG Status
VG #
MAX LV
Cur LV
Open LV
MAX LV Size
Max PV
Cur PV
Act PV
VG Size
PE Size
Total PE
Alloc PE / Size
Free PE / Size
VG UUID
volume1
read/write
available/resizable
0
256
1
0
255.99 GB
256
1
1
5.59 GB
4 MB
1430
150 / 600 MB
1280 / 5 GB
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
39
Commandes complémentaires
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
où
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
où
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
40
Une fonction particulière du LVM : la réalisation d
Système de
fichiers
diminution
Augmentation
Utilitaires
ext3
démontage préalable
e2fsprogs (resize2fs)
ReiserFS
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 :
41
Evolution du LVM : LVM 2
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 :
• linear : c'est le cas le plus couramment utilisé dans le LVM. Les arguments nécessaires seront alors le device utilisé et le secteur de début.
• stripped : on utilisera cette cible lorsque l'on réalise du stripping avec le LVM. Les arguments seront alors le nombre de stripes et leur taille,
puis les paires device name / secteurs.
• error : toutes les I/O sur les secteurs ainsi marquées sont définies en erreur.
• snapshot : permet de réaliser des snapshots asynchrones grâce au LVM.
• mirror : permet d'implémenter les éléments nécessaires à l'exécution de la commande pvmove.
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 :
• les devices à utiliser pour réaliser le LVM, ce qui permet d'éviter des scans de périphériques inutiles et qui nuisent à la performance (ex :
lecteur de CD−ROM). A cela, on ajoute la gestion d'un système de cache contenant ces informations qui permet d'accroitre encore plus
l'efficacité.
• possibilité de déterminer l'emplacement des fichiers spéciaux des groupes volumes
• possibilité de disposer de logs configurables (taille, contenu, emplacement, ...)
• paramétrage des backups de la configuration existante et de l'archivage des anciennes configuration du LVM (métadatas)
• définition du type de LVM employé par défaut (1 ou 2), même s'il est possible dans la compilation de n'inclure que la gestion du LVM2, dans
le cas où la gestion de la compatibilité descendante n'est pas nécessaire.
• définition du nombre de copies de secours des métadatas sur un volume physique, un peu à l'image des copies des superblocs sur le
système de fichiers de type ext2.
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
42
Autre
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
• HOWTO LVM : http://tldp.org/HOWTO/LVM−HOWTO
• La principale mailing−liste d'aide : http://lists.sistina.com/mailman/listinfo
• Trouver les sources de LVM : http://www.sistina.com/products_lvm.htm
• Un autre projet de gestion de volumes logiques, EVMS : http://evms.sourceforge.net
43
QoS/Gestion de la bande passante sous Linux
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
• Minimize−Delay : Améliore la réactivité des connexions en réduisant le délai (ssh, telnet, ftp contrôle, tftp, flux DNS UDP)
• Maximize−Throughput : Améliore le débit au prix d'une possible détérioration de l'interactivité de la session. Les temps de latence ne sont
pas importants (ftp−data,www, transfert de zone DNS)
• Maximum−Reliability : Certitude que les données arrivent sans perte − Améliore la fiabilité (snmp, smtp)
• Minimize monetary cost : minimise le délai, meilleure rentabilité (nntp, icmp)
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 :
• Les filtres qui placent le trafic dans les files d'attentes (fwmark, u32)
• Les files d'attentes qui décident des flux prioritaires (CBQ, HTB, RED, TBF, SFQ...)
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)
44
Gestion de la bande passante sou
Les options
Dans la partie "Networking Options" −> "QoS and fair queuing" :
Option Noyau
Sélection à
la
Définition
Compilation
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
module
pseudoscheduler
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
(Queuing discipline) − Indispensable lorsque l'on souhaite utiliser les files d'attente
Ingress QDisc
module
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
module
classifier for IPv6
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 :
• make dep
• make clean
• make bzImage
• make modules
• make modules_install
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é là)
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.
45
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
• convient à de petits débits
• nécessite de connaître la taille moyenne des paquets et la vitesse maximale de la connexion
• utilise le temps d'inactivité de la connexion pour calculer une approximation du débit utilisé.
HTB.init : file d'attente HTB
• convient à des gros débits
• consomme peu de ressources
• ne fait pas d'approximation en ce qui concerne le calcul du débit
• nécessite de connaitre le débit maximal de votre connexion.
Wondershaper : file d'attente HTB
• maintient une bonne réactivité pour le traffic interactif (ssh, telnet...)
• surfer sans souci lors de gros downloads
• s'assure que l'upload ne défavorise pas le download et inversement.
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
RULE=192.128.1.50:80,
46
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
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
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)
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
47
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
48
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,
49
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 :
• maintient une bonne réactivité pour le traffic interactif (ssh, telnet...)
• vous pouvez surfer sans soucis lors de gros downloads
• l'upload ne défavorise pas le download et inversement.
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
50
# 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é.
51
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
# 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
# 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
# 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
52
# 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
53
Script de visualisation des files d'attentes
# 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 : [email protected]
54
Crypter un système de fich
Crypter un système de fichiers
par Meuh
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 :
• celle de http://kerneli.org, disponible sous forme de patch pour les noyaux 2.2 et 2.4. Cette API est développée par Alexander Kjeldaas, Hebert
Valerio Riedel , Kyle McMartin, Jean−Luc Cooke, David Bryson, Clemens Fruhwirth, Tobias Ringstrom, Harald Welte.
• celle du noyau 2.5/2.6 et maintenant 2.4.22. Cette version est un dérivé simplifié d'API de http://kerneli.org destinée à l'implémentation d'IPSec. Elle a
été développée par James Morris et David S. Miller
À 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 :
• Les sources du noyau 2.4.22,
• Un patch cryptoloop pour étendre le fonctionnement du périphérique loop et intégrer le support de la cryptographie : soit
patch−cryptoloop−jari−2.4.22.0, soit patch−cryptoloop−hvr−2.4.22.0 .
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 :
55
• les sources de util−linux−2.12 : la dernière version intégre un support minimal de la cryptoapi, et supporte la nouvelle version de la loop device
présente dans le 2.6.
Ou bien :
• les sources de util−linux−2.11z
• le patch util−linux−2.11z−crypto−v2.diff.bz2 développé par Jari Ruusu. Le patch de Jari supporte loop−AES, la crypto api, et des fonctions évoluées
pour la saisie du mot de passe.
À 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.
56
# 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é.
57
−− 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
58
$ 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 :
• empêchez l'ouverture de l'ordinateur,
• empêchez l'utilisation de disque d'amorçage autre que le disque dur,
• sécurisez l'amorçage du système d'exploitation : une personne non autorisée ne doit pas pouvoir passer de paramètres au noyau.
• ne laisser jamais de session ouverte sans protection, verrouillez votre terminal dès que vous le quittez.
• archivez vos données de façon cryptée.
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é.
59
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
• Crypto API (original) http://www.kerneli.org/
• Util Linux 2.12 : http://www.kernel.org/pub/linux/uti...
• Patchs cryptoloop pour le kernel 2.4.22 :
http://www.kernel.org/pub/linux/ker...
http://www.kernel.org/pub/linux/ker...
http://encryptionhowto.sourceforge.net/
• patch util−linux 2.11z (Jari Ruusu) :
http://therapy.endorphin.org/patches/
http://www.kerneli.org/pipermail/cr...
• patches pour étendre les util−linux 2.12 : http://www.stwing.org/~sluskyb/util...
• explication cryptoapi : http://www.kerneli.org/pipermail/cr...
• quelques informations :
http://www.abeowitz.com/crypto/
http://sourceforge.net/projects/cry...
• crypto api 2.5 par James Morris : http://samba.org/~jamesm/crypto/
• Le projet de cryptographie (loop + crypto) de Jari : http://loopaes.sourceforge.net/
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.
60
Une solution de groupware OpenS
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 :
61
L'annuaire LDAP
# 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
62
Le support de la messag
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 = (ilUser)(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 = (lRecipient)(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.
63
L'installation de eGroupWare
# 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.
64
L'installation de eGroupW
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.
65
Configuration 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.
66
Configuration du groupw
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.
67
Revue de détail des principales applications
• 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.
68
Sécurisation et optimisation de l'ins
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.
69
Liens
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
70

Section Pro de Léa

Transcription

Documents pareils

Contact Parc d`activités des Hauts de France 2 Parc d`activités Haut

Tsovranien urban

Etape 1 : Installer OpenGL avec Dev c++

HOWTO - Recover a Lost Linux Password

Pilote ntfs-3g

Télécharger la présentation de la banque mondiale

hayri dev musique de yayla

Extrait du livre

format pdf - Stéphane List