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 Léa pour les pros ! 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, Léa pour les pros ! 1 Léa pour les pros ! 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 Léa pour les pros ! 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) Léa pour les pros ! 3 I) La disponibilité des services 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 Léa pour les pros ! 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é. Léa pour les pros ! 5 I) La disponibilité des services 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 Léa pour les pros ! 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. Léa pour les pros ! 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 Léa pour les pros ! 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. Léa pour les pros ! 9 III) De la théorie à la pratique 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 Léa pour les pros ! 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. Léa pour les pros ! 11 III) De la théorie à la pratique 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 Léa pour les pros ! 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 :) Léa pour les pros ! 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. III) Les exemples concret de haute disponibilité. A l'aide des connaissances acquises ci−dessus, nous pouvez établir quelques exemples pour des services de haute disponibilité. Nous décrirons aussi les avantages et les inconvénients de chaque solution. A. FailOverServices Simples Nombre de machines minimum nécessaire : 2 Logiciels ou matériels nécessaires : HeartBeat + services multipliés par le nombre de serveurs. 14 Léa pour les pros ! 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 Nombre de machines minimum nécessaire : 2 Logiciels ou matériels nécessaires : HeartBeat + Raid + services multipliés par le nombre de serveurs. Léa pour les pros ! 15 III) Les exemples concret de haute disponibilité. • 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 Nombre de machines minimum nécessaire : 2 Logiciels ou matériels nécessaires : HeartBeat + Système de fichier de réplication + les services multipliés par le nombre de serveurs. 16 Léa pour les pros ! III) Les exemples concret de haute disp • 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 Nombre de machines minimum nécessaire : 3 Logiciels ou matériels nécessaires : heartBeat + NFS (ou équivalent) + les services multipliés par le nombre de serveurs−services. Léa pour les pros ! 17 III) Les exemples concret de haute disponibilité. • 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 Léa pour les pros ! III) Les exemples concret de haute disp E. FailOverServices Simples avec utilisation d'un serveur de données "FailOveriser" réplication réseau Nombre de machines minimum nécessaire : 4 Logiciels ou matériels nécessaires : heartBeat + NFS (ou équivalent) + Système de fichiers réplication réseau + les services multipliés par le nombre de serveurs−services. Léa pour les pros ! 19 III) Les exemples concret de haute disponibilité. 20 Léa pour les pros ! III) Les exemples concret de haute disp • 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 Nombre de machines minimum nécessaire : 4 Logiciels ou matériels nécessaires : heartBeat + NFS (ou équivalent) + Système de fichiers réplication réseau + RAID + les services multipliés par le nombre de serveurs−services. Léa pour les pros ! 21 III) Les exemples concret de haute disponibilité. 22 Léa pour les pros ! III) Les exemples concret de haute disp • 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 ? :) Léa pour les pros ! 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 Léa pour les pros ! 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. Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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' # privileged ports: reject or deny FIREWALL_DENY_PORT_2='54:112 REJECT' # privileged ports: reject or deny FIREWALL_DENY_PORT_3='114:1023 REJECT' # imond/telmond ports: reject or deny FIREWALL_DENY_PORT_4='5000:5001 REJECT' # proxy access: reject or deny FIREWALL_DENY_PORT_5='8000 REJECT' # vbox server access: reject or deny FIREWALL_DENY_PORT_6='20012 REJECT' # deny icmp (ping): yes or no FIREWALL_DENY_ICMP='no' # log access to rejected/denied ports FIREWALL_LOG='yes' #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # Domain configuration: #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # start dns server: yes or no START_DNS='yes' # DNS servers of your provider, e.g. MSN (free.fr) DNS_FORWARDERS='212.27.32.5' # log queries in /usr/local/ens/ens.log DNS_VERBOSE='no' # your domain name DOMAIN_NAME='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 Léa pour les pros ! 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): Léa pour les pros ! 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 Léa pour les pros ! 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' Léa pour les pros ! # 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 Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! Une fonction particulière du LVM : la réalisation d Système de fichiers diminution Augmentation Utilitaires ext3 démontage préalable démontage préalable e2fsprogs (resize2fs) ReiserFS démontage préalable opération on−line reiserfsprogsv (resize_reiserfs) XFS impossible opération on−line xfsprogs (xfs_growfs) Une fonction particulière du LVM : la réalisation de snapshots La difficulté fréquemment rencontrée pour la réalisation de sauvegardes est de disposer de données cohérentes. Cela implique parfois d'arrêter un ou plusieurs services comme dans le cas des bases de données. Le LVM apporte un élément de réponse avec la possibilité de créer des snapshots. Il s'agit d'image à un moment t des données situées sur un volume logique. Le volume de snapshot ne nécessite pas autant d'espace que le volume initial dans la mesure où il ne contiendra réellement que les métadatas concernant les données à sauvegarder. Autres commandes Cet article n'abord era pas le détail de toutes les commandes, qui sont plutôt simples à utiliser une fois que les concepts de base du LVM sont compris. Dans le tableau ci−aprè une liste de commandes utilisables et la description rapide de leur rôle. Voir le man de la commande pour plus d'informations. Commandes générales • lvmcreate_initrd : création d'une image initrd lorsque le système utilise le LVM • lvmdiskscan : scanner l'ensemble des disques et partitions pour éditer une description de l'espace • vgscan : création de /etc/lvmtab et /etc/lvmtab.d Gestion des volumes physiques • pvchange : changer les attributs d'un PV • pvcreate : création d'un PV • pvdata : afficher des informations de debug • pvdisplay : afficher des informations d'un PV • pvscan : lister tous les PV existant sur tous les disques Gestion des groupes de volumes • vgcfgbackup : sauvegarder la VGDA • vgcfgrestore : restaurer la VGDA • vgchange : changer les attributs d'un VG • vgck : vérification de la VGDA • vgcreate : créer un VG • vgdisplay : voir les informations • vgexport : désactiver un VG pour pouvoir extraire les PV • vgimport : activer et déclarer un VG sur le système • vgextend : ajouter un ou plusieurs PV dans un VG • vgmerge : fusionner deux VG • vgmknodes : recréer /dev/nom_volume et le fichier spécial group • vgreduce : extraire un ou plusieurs PV d'un VG • vgremove : supprimer un VG • vgrename : renommer un VG Gestion des volumes logiques • lvcreate : création d'un VL lvchange : modification des attributs d'un VL • lvdisplay : voir les informations d'un VL • lvextend : augmenter la taille d'un VL • lvreduce : réduire la taille d'un VL • lvremove : supprimer un VL • lvrename : renommer un VL • lvscan : recherche de tous les VL existant Utilisation pratique du LVM dans la gestion de l'espace Vous diposez d'un groupe de volume dans lequel vous n'avez plus d'espace disponible. Pour pouvoir augmenter un des volumes logiques, il va donc falloir ajouter un disque au groupe de volume. Comme pour tout élément du LVM, la première étape consiste à le transformer en volume physique ("pvcreate"). Puis on va insérer le nouveau volume physique dans le groupe de volume au moyen de la commande "vgextend". C'est tout ! Plus complexe, vous pouvez, pour quelle que raison que ce soit, envisager de déplacer un groupe de volume d'une machine à une autre. Si une sauvegarde de données est toujours conseillée par sécurité (mais comme vous êtes prévoyant vous en disposez de toute façon ;)), l'opération va consister à désactiver le groupe de volume à déplacer, enregistrer les métadatas le concernant. Puis on va réinjecter ces métadatas sur la machine destinataire et réactiver le groupe de volume sur cette machine. Les données seront alors accessibles de la même façon que sur l'ancienne machine (sous réserve de conserver les mêmes points de montage). Ci−dessous les étapes effectuées : Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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 Léa pour les pros ! 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. Léa pour les pros ! 45 Gestion de la bande passante sous Linux 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 RATE=64Kbit # Exprimez les valeurs en Kbit ou Mbit selon les débits spécifiés WEIGHT=6Kbit # WEIGHT = RATE / 10 PRIO=5 # Va de 1 à 8 , 1 etant le + prioritaire (la valeur 5 est recommandée et suffisante pour prioriser un traffic spécifique) RULE=192.128.1.50:80, 46 Léa pour les pros ! Gestion de la bande passante sou Exemple 4 : $CBQ_PATH/cbq−1280.My_fourth_shaper − vous souhaitez limiter le traffic des gens qui download sur votre serveur ftp (192.168.1.50) à 10 Ko/s DEVICE=eth0,10Mbit,1Mbit # 10 Mbits −> debit max de l'interface de votre serveur ftp RATE=80Kbit # Exprimez les valeurs en Kbit ou Mbit selon les débits spécifiés WEIGHT=8Kbit # WEIGHT = RATE / 10 PRIO=5 # Va de 1 à 8 , 1 etant le + prioritaire (la valeur 5 est recommandée et suffisante pour prioriser un traffic spécifique) RULE=192.128.1.50:20/0xfffe # limitation de BP appliquée sur port 20/21 Exemple 5 : $CBQ_PATH/cbq−1280.My_fifth_shaper − vous souhaitez que le traffic LAN −> INTERNET soit limité à 50 Ko/s (400 Kbits/s), et que le traffic INTERNET −> LAN soit limité à 10Ko/s (80 Kbits/s), remplissez CBQ.init de la manière suivante : LAN −−−−− eth0 [LINUX] eth1 −−−−− INTERNET ######################## {{ LAN −> INTERNET }} #################################### DEVICE=eth1,10Mbit,1Mbit RATE=400Kbit WEIGHT=40Kbit # WEIGHT = RATE / 10 PRIO=5 BOUNDED=yes # Pour ne pas aller prendre de la BP aux classes parents ISOLATED=NO # Permet de léguer de la BP aux classes filles si il en reste RULE=192.168.0.0/24 # Le partage de BP concerne le traffic a destination du reseau 192.168.0.0 ############################################################ ############ ######################## {{ INTERNET −> LAN }} #################################### DEVICE=eth0,100Mbit,10Mbit # RATE=80Kbit # On souhaite limiter le traffic entrant à 10 Ko/s (adaptez selon le debit de votre ligne) WEIGHT=8Kbit # WEIGHT = RATE / 10 PRIO=5 BOUNDED=yes ISOLATED=NO RULE=80,192.168.1.10 # Tout le traffic HTTP INTERNET −> 192.168.1.10 limité à 10 Ko/s #################################### #################################### Il ne reste plus qu'à lancer le script CBQ.init à chaque démarrage ; pour cela éditez le /etc/rc.d/rc.local et ajoutez la ligne "CBQ.init−[version] start" où [version] désigne la version de votre script CBQ. Si vous souhaitez obtenir des statistiques CBQ, lancez la commande "CBQ.init−[VERSION] stats". Le script vous sortira des informations qui peuvent s'avérer utile. Voilà, vous êtes désormais un gourou des files d'attentes CBQ :). Passons maintenant à la gestion de la BP avec file d'attentes HTB. HTB.init Récupérez le script HTB.init à l'adresse suivante : http://sourceforge.net/projects/htbinit Notes pour noyau < 2.4.18−3 : pour utiliser des files d'attentes HTB, sachez que vous devez patcher votre noyau si il est inférieur à la version 2.4.18−3 (tapez "uname −a" pour vérifier la version de votre distribution) : http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.4.17.diff pour les noyaux 2.4 http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.2.17.diff pour les noyaux 2.2 Pour appliquer le patch lancez la commande suivante dans le répertoire /usr/src/linux : "patch −pl −i htb2_2.4.17.diff" Dans /usr/src/linux tapez : "make xconfig" Dans la partie "Networking Options" −> "QoS and fair Queuing", selectionnez HTB packet scheduler en module Recompilez le noyau : "make dep &make clean &make bzImage &make modules &make modules_install" Mettez en place le nouveau noyau qui prend en charge HTB : cp /usr/src/linux/arch/i386/bzImage /boot/vmlinuz cp /usr/src/linux/arch/i386/boot/System.map /boot Vous devez aussi mettre à jour la commande "tc" : http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz Faites un "chmod u+x HTB.init−[VERSION]" afin de le rendre executable. Copiez le script dans le répertoire /usr/bin : "cp HTB.init−[VERSION] /usr/bin" Créez le répertoire /etc/sysconfig/htb qui contiendra les fichiers de gestion de BP sur lequelles se basera le script : "mkdir /etc/sysconfig/htb" − Si vous souhaitez placer vos fichiers de configurations HTB ailleurs, modifiez la variable $HTB_PATH dans le script HTB.init afin de renseigner le nouveau chemin. Exemples de fichiers de configurations HTB.init : Il n'existe pas un mais plusieurs fichiers de configurations pour HTB.init. Les fichiers doivent obligatoirement avoir une syntaxe précise. Par exemple : eth0−2 −> classe root ID 2, device eth0 eth0−2:3 −> classe fille ID 3, ayant comme parent 2, device eth0 eth0−2:3:4 −> classe fille ID 4, ayant comme parent 3, device eth0 eth1−2.root −> classe root ID 2, device eth1 Léa pour les pros ! 47 Gestion de la bande passante sous Linux 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 Léa pour les pros ! Gestion de la bande passante sou 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, Léa pour les pros ! 49 Gestion de la bande passante sous Linux 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 Léa pour les pros ! Gestion de la bande passante sou # 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é. Léa pour les pros ! 51 Gestion de la bande passante sous Linux ip link set dev $DEV qlen 30 # modification de MTU du périphérique sortant. # − Diminuer la MTU abaisse la latence mais dégrade le débit en raison de # la surcharge IP et TCP. ip link set dev $DEV mtu 1000 # ajout de la stratégie HTB tc qdisc add dev $DEV root handle 1: htb default 26 # ajout de la classe de limitation principale tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit # ajout des classes filles: # − chaque classe dispose AU MOINS de son quota de bande passante. Aucune # classe n'est donc étouffée par les autres. Chaque classe peut également # consommer toute la bande passante si aucune autre classe ne l'emploie. tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[$RATEUP/7]kbit \ ceil ${RATEUP}kbit prio 0 tc class add dev $DEV parent 1:1 classid 1:21 htb rate $[$RATEUP/7]kbit \ ceil ${RATEUP}kbit prio 1 tc class add dev $DEV parent 1:1 classid 1:22 htb rate $[$RATEUP/7]kbit \ ceil ${RATEUP}kbit prio 2 tc class add dev $DEV parent 1:1 classid 1:23 htb rate $[$RATEUP/7]kbit \ ceil ${RATEUP}kbit prio 3 tc class add dev $DEV parent 1:1 classid 1:24 htb rate $[$RATEUP/7]kbit \ ceil ${RATEUP}kbit prio 4 tc class add dev $DEV parent 1:1 classid 1:25 htb rate $[$RATEUP/7]kbit \ ceil ${RATEUP}kbit prio 5 tc class add dev $DEV parent 1:1 classid 1:26 htb rate $[$RATEUP/7]kbit \ ceil ${RATEUP}kbit prio 6 # ajout de la stratégie aux classes filles # − SFQ offre un traitement sensiblement équitable de chaque classe. tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 10 tc qdisc add dev $DEV parent 1:22 handle 22: sfq perturb 10 tc qdisc add dev $DEV parent 1:23 handle 23: sfq perturb 10 tc qdisc add dev $DEV parent 1:24 handle 24: sfq perturb 10 tc qdisc add dev $DEV parent 1:25 handle 25: sfq perturb 10 tc qdisc add dev $DEV parent 1:26 handle 26: sfq perturb 10 # répartition du trafic en classe via fwmark # − le trafic est réparti en classes de priorité suivant l'indicateur # fwmark des paquets (ceux−ci sont positionnés avec iptables un peu plus # loin). La classe de priorité par défaut a été mise à 1:26 de telle sorte # que les paquets qui ne sont pas marqués se retrouvent dans la classe de # priorité la plus faible. tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:22 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 23 fw flowid 1:23 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 24 fw flowid 1:24 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 25 fw flowid 1:25 tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26 # ajout de MONLIMITEUR−OUT à la table de modification des paquets d'iptables # − ceci déclare la table employée pour filtrer et classer les paquets iptables −t mangle −N MONLIMITEUR−OUT iptables −t mangle −I POSTROUTING −o $DEV −j MONLIMITEUR−OUT # ajout de fwmark pour classer les différents types de trafic # − fwmark est positionné de 20 à 26 suivant la classe. 20 correspond à la # priorité la plus forte. # Trafic sur les ports bas iptables −t mangle −A MONLIMITEUR−OUT −p tcp −−sport 0:1024 −j MARK −−set−mark 23 # Trafic sur les ports bas iptables −t mangle −A MONLIMITEUR−OUT −p tcp −−dport 0:1024 −j MARK −−set−mark 23 # Port ftp−data, faible priorité iptables −t mangle −A MONLIMITEUR−OUT −p tcp −−dport 20 −j MARK −−set−mark 26 52 Léa pour les pros ! Gestion de la bande passante sou # 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 Léa pour les pros ! 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 Léa pour les pros ! 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 : Léa pour les pros ! 55 Crypter un système de fichiers • 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 Léa pour les pros ! Crypter un système de fich # 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é. Léa pour les pros ! 57 Crypter un système de fichiers −− 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 Léa pour les pros ! Crypter un système de fich $ 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é. Léa pour les pros ! 59 Crypter un système de fichiers 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 Léa pour les pros ! 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 : Léa pour les pros ! 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 Léa pour les pros ! 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. Léa pour les pros ! 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éa pour les pros ! 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. Léa pour les pros ! 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 Léa pour les pros ! 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. Léa pour les pros ! 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 Léa pour les pros ! 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. Léa pour les pros ! 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 Léa pour les pros !