Pour plus d’info ==> http://www.nuitduhack.com/
J’ai déjà fait les deux précédentes, je vous invite à participer activement a celle-ci.
Lorsque nous avons un serveur VPN comportant beaucoup d’utilisateurs, il devient rapidement difficile à administrer. Surtout dans le cadre de révocation de client, ajout de nouveaux utilisateurs etc …
Pour cela j’ai découvert un GUI web permettant de :
|
|
Ce projet est encore en développement, cependant il reste a suivre de près car les fonctionnalités annoncé m’ont l’air prometteuse.
La liste des dépendances est la suivante : apache2, php5, php5-session, php-pcre, smarty. Il faut obsolument que php soit installé avec le support ssl (–with-openssl).
Une fois les dépendances satisfaites, il ne reste plus qu’a télécharger et décompressé l’archive ==> http://openvpn-web-gui.sourceforge.net/
Il faut éditer le fichier config.inc pour renseigner les différents chemins du fichier de configuration de openvpn et du fichier de log.
IMPORTANT : il faut qu’openvpn génére un fichier de log version 2. Il faut donc ajouter status-version 2 au fichier de conf
Voici la liste des utilisateurs connectés :
Ainsi que la liste des certificats et des users creés :
Les RAID qui utilise le stripping améliore les performances en partageant les fichiers en petites pièces et en les distribuant aux multiples disques durs. La plupart des mises en oeuvre de stripping permettent à l’administrateur plus de deux paramètres critiques qui définissent comment les données sont splittés, et envoyé aux différents disques durs. Chacun de ces facteurs a un impact important sur les performances du RAID.
Le premier paramètre clef est le stripe width du RAID. Le stripe width se réfère au nombre de stripes parallèles qui peuvent être écrites ou lu simultanément. C’est bien sûr égal au nombre de disques dans le tableau. Donc un RAID à quatre disques aurait un stripe width de quatre.
Les performances de lecture et écriture d’un RAID strippé augmente en même temps que le stripe width augmente. La raison est que l’ajout de disques durs au RAID augmente le parallélisme RAID, donnant ainsi l’accès à plus de disques durs simultanément.
Vous aurez généralement un taux de transfert plus performant d’un RAID comprenant huit disques durs de 18GB que d’un RAID de 36GB, tout en ayant le mêmes gammes de disques durs.
Bien sûr, le coût de huit disques durs de 18GB est plus onéreux que quatre disques durs de 36GB, tout en prenant compte la puissance nécessaire au niveau des alimentations.
Le second paramètre clef est le stripe size du RAID, quelques fois on retrouve ce terme comme la taille des blocs, longueur des blocs… Ce terme fait référence à la taille des blocs écrit sur chaque disques. Les RAID autorise la taille des blocs compris entre 2KB et 512KB (voir plus), chaque blocs est multiple de deux (2KB, 4KB, 8KB, …). Les RAID de type 3, n’autorise que un stripe size de 1B, voir moins, et n’est pas modifiable par l’utilisateur.
L’impact au niveau des performances du stripe size est plus difficile a quantifier que l’effet du stripe width.
Réduction du Stripe Size: comme le stripe size est réduit, alors les fichiers sont coupés en de plus petites pièces. Cela augmentera le nombre de disques contenant le fichier, en théorie, cela augmente le temps de transferts, mais ça réduit les performances de positionnement.
Augmentation du Stripe Size : l’augmentation du stripe size du RAID, fait l’opposé de ce que nous avons vu précédemment. Il faudra moins de disques durs pour contenir le fichier, du coup les performances de transferts seront réduites. Mais si le contrôleur est optimisé pour, la condition d’avoir moins de disques durs, permet aux disques durs non nécessaires d’avoir un accès particulier ceci afin d’être utilisé pour un autre transfert, améliorant la performance du positionnement
Voici un exemple de deux différents disques avec des stripes size différents:
A gauche, un RAID 0 de quatre disques avec un stripe size de 4 KB; à droite le même RAID avec les mêmes données, mais qui utilise un stripe size de 64 KB. Dans ce diagramme, quatre fichiers se distinguent par quatre couleurs différentes:
Ils sont dessiné afin d’illustrer combien d’espace ils occupent en terme relatif dans le RAID (un pixel vertical représente 1KB).
On peut constater la différence de traitement de fichier entre les deux type de RAID. Les fichiers de 4KB prennent seulement un bloc sur un seul disque dans les deux RAID, et le fichier de 500KB est répartie au travers des quatre disque dans les deux RAID. Mais quand le plus large stripe size est utilisé, le fichier bleu apparaît seulement sur un seul disque à la place de quatre, et le fichier vert est réparti sur deux disques au lieu de quatre. Ceci améliore le positionnement aléatoire de ces fichiers. Dans les deux cas, le stripe width est bien sur de quatre.
Alors quel stripe size choisir ? La meilleur solution pour trouver lequel convient le mieux, est d’essayer plusieurs valeurs: plus ça empire, moins la solution sera bonne 
En outre, ne surestimez pas les performances entre les différents taille de stripe size, elle peut être significative, en particulier si vous prenez les opposés du spectre comme par exemple 4KB et 256KB, mais la différence n’est pas souvent aussi large entre deux valeurs.
Et si vous devez avoir un principe de base, je dirais ceci : les environnements transactionnels où vous avez un grand nombre de lecture et d’écriture sont probablement plus aisés avec une grande tailles de stripe size; les applications où de plus petits nombres de grand fichiers doivent être lus rapidement préféreront probablement de plus petit stripe size. Évidemment, si vous devez équilibrer ces conditions, choisissez quelque chose au milieu.
http://www.storagereview.com/guide2000/ref/hdd/perf/raid/concepts/perfStripe.html
J’ai ouvert le challenge de sécurité au public.
Ca ce passe ici ==> http://corbier.homelinux.com/wordpress/
Introduction à LVM
LVM, dont l’acronyme anglo-saxon signifie Logical Volume Manager, est un gestionnaire de
volumes logiques qui apportent une vision abstraite du stockage de votre machine. La partition
physique devient un composant élémentaire et ne va plus directement supporter le système de
fichiers. Entre ces deux couches de bas et de haut niveau (successivement, la partition et le système
de fichiers), vont s’intercaler une première couche regroupant les partitions physiques (appelée
« volume groupe ») et une deuxième couche dans laquelle nous allons créer les systèmes de fichiers
(appelés « volumes logiques ») mais qui seront dynamiquement retaillables (indifféremment en
réduction ou en extension).
Figure 1 : Découpage des données sous LVM
L’intérêt principal de cette approche est à la fois de pouvoir étendre facilement un volume groupe en
ajoutant des partitions physiques (par exemple, un nouveau disque dur) et de changer la taille à
chaud des volumes logiques sachant que ces derniers ne possèdent pas un emplacement précis sur
un volume groupe et ne sont représentés que par leur nom et leur taille. Voici un exemple de ce que pourrait donner un système tournant sur LVM.
Figure 2 : Couches d’abstractions du modèle LVM
Le nommage des volumes groupes et logiques est libre même si la convention habituelle est de préfixer un volume groupe par « vg_ » et un volume logique par « lv_ ».
Tout l’espace disponible dans un volume groupe peut ne pas être utilisé dans les volumes logiques.
Cela permet de garder en réserve de l’espace disque pour l’ajouter aux volumes logiques qui en
auront besoin.
LVM (dont les principes ont été développés par l’Open Software Foundation) est notamment un
ticket d’entrée incontournable dans le monde de l’entreprise actuel. Il faut bien comprendre que les
gros Unix propriétaires possèdent tous leurs propres gestionnaires de volumes : Aix, Solaris, HP-
UX, Tru64, … (l’implémentation actuelle LVM de Linux, qui en est à sa version 1.0.7, est très
proche de celle de HP-UX). Linux n’est donc pas un précurseur en la matière mais disposer d’un
LVM est un enjeu primordial pour les décideurs informatiques souhaitant traiter des volumes de
données conséquents.
LVM 1.0.x (développé principalement par la société Sistina) est directement implémenté au niveau
du noyau Linux depuis sa version 2.4 (avec possibilité d’implémentation à partir du 2.2.17) ; la
version 2.6 qui devrait arriver fin 2003 va intégrer la version 2.0 de LVM. Cette dernière version
repose sur une nouvelle couche du noyau, le « device mapper », qui rationalise l’implémentation de
drivers supportant des devices virtuels en mode blocs comme par exemple le Raid logiciel. On peut
donc s’attendre à de meilleures performances et une plus grande fiabilité.
Pour la petite histoire, il s’en est fallu de peu que le LVM Linux ne soit supplanté par un équivalent
développé par IBM, appelé du doux acronyme de EVMS, et qui avait pour ambition de modifier la
vision que l’on pouvait avoir du stockage de données sous Linux en fédérant l’essentiel des couches
dans un même outil : partition, LVM, Raid logiciel, etc. (concept qui avait tout pour séduire). Les
développeurs du noyau Linux ont finalement tranché en faveur du LVM2 de la startup Sistina plutôt
que de choisir l’outil novateur (peut être un peu trop) du géant IBM : cela est la preuve, s’il en est
besoin, de l’approche démocratique et mature du développement du noyau Linux.
Autant être honnête, les fonctionnalités du driver EVMS restent très alléchantes à l’heure qu’il est ;
la preuve en est que le projet continue d’être développé comme vous pourrez le constater sur le site
officiel chez IBM. Peut être entendrons-nous un jour reparler de cet outil sous une forme différente ?
Après avoir lu le début de cet article, vous avez peut être la désagréable impression qu’utiliser un
gestionnaire de volumes est exclusivement réservé aux sociétés qui manipulent de grosses quantités
de données. Cette impression est fausse car LVM peut être aussi très utile sur la machine d’un
particulier, en fait sur n’importe quelle configuration.
Vous êtes un particulier et vous possédez une machine disposant d’un disque dur de 40 Go : vous
échangez régulièrement beaucoup de fichiers avec vos amis et cela entraîne une saturation du
répertoire /home ? Vous installez régulièrement de nouveau logiciels et votre /usr ne peut plus tenir
la cadence ? Une utilisation intensive de la machine cause la génération de fichiers de log qui
remplissent la partition supportant /var ? Avec LVM, il vous sera possible de préparer votre
machine avec des tailles de partitions adaptées en prévision de leur occupation théorique et, en cas
de nécessité, il vous sera possible d’adapter au fur et à mesure des besoins la taille des partitions à
leur utilisation réelle.
Vous êtes un ingénieur système et le volume de données à traiter de votre société est en continuelle
augmentation ? Avec LVM, il vous suffira de rajouter un nouveau disque dur (en SCSI, cela peut
même être fait à chaud) et de l’ajouter dans un de vos volumes groupes. L’espace nouvellement
affecté pourra être utilisé par les systèmes de fichiers les plus demandeurs en quelques commandes.
C’est même souvent utilisé pour isoler les applications critiques en créant un volume groupe par
application : vous gardez le contrôle de l’occupation disque et vous sécurisez votre système en cas
de débordement d’une application dont la volumétrie a été sous évaluée.
Le LVM Linux n’intègre pas directement le support du Raid1 (mode miroir ou les données sont
dupliquées sur au moins 2 disques pour supporter la perte d’un disque). Il faut pour cela utiliser une
carte raid hardware ou plus simplement le driver Linux MD (Linux Multiple Device) : LVM utilise
autant des partitions physiques que des partitions créées par Raid logiciel. Par contre, le support du
mode striping (les données sont écrites par morcellement sur plusieurs disques dur pour améliorer
les performances) est natif. Dans une utilisation professionnelle, l’utilisation d’une carte raid est tout
de même fortement conseillée vu son faible coût.
La plupart des distributions Linux récentes dispose du support LVM. La configuration du volume
manager est accessible aussi à l’installation de votre machine, au moins sur les distributions
RedHat, SuSE et Mandrake (l’installation se fait en mode graphique). Cela est aussi possible par
défaut sur la distribution Debian à partir de la version etch.
Le Clustered Logical Volume Manager (CLVM) est un ensemble d’extensions de cluster de LVM. Ces extensions permettent à un cluster de machine de gérer un stockage partagé (par exemple un SAN) tout en utilisant LVM.
Le daemon clmvd est l’outil qui permet le fonctionnement de LVM en cluster. Le deamon clvmd tourne sur chaque machine constituant le cluster et distribue les mises à jours des metadatas LVM au sein du cluster , présentant chaque machine fesant parti du cluster avec la même vue du volume logique.
Figure 3, Vue d’une architecture CLVM dans un Cluster Red Hat.
Les volumes logiques créer avec CLVM sur un stockage partagé sont visibles à toutes les machines qui ont accès à ce stockage partagé.
CLVM permet a un utilisateur de configurer des volumes logiques sur un stockage partagé en verrouillant l’accès au stockage physique pendant que le volume logique est en train d’être configuré.
Dans LVM, un volume group est divisé en volumes logiques. Il a trois type de volumes : volume linéaire, volume strippé, et volume mirroré.
Un volume linéaire agrège plusieurs volume physique en un seul volume logique. Par exemple, si Vous avez deux disque de 60 GB, vous pouvez créer un disque logique de 120 GB. Les volumes physiques sont donc concaténés.
Figure 4: Exemple d’un volume linéaire
Quand vous écrivez des données sur un volume logique, le système réparti les donnés dans l’ensemble des disques physiques. On peut contrôler l’écriture sur les volumes physiques en créant un volume logique strippé. Pour les E/S importantes, cela peut améliorer les performances. Le stripping augmente les performances en écrivant les données dans un nombre prédéterminé de disques physiques en mode série. Avec le stripping, les E/S peuvent être fait en parallèles. Dans certaines situations, cela peut entraîner une performance linéaire pour chaque disque physique installé.
Figure 5: cas d’un volume strippé
Il est possible de spécifier sur quel partie du disque vous voulez utiliser. En effet si c’est un accès fréquent que l’on cible, alors on choisira le début du disque. En revanche, pour un accès moins fréquent comme des sauvegardes, alors la fin du disque semble être toute désignée pour accueillir ce genre de données.
Un miroir maintient un copie identiques des données contenu sur différent périphériques. Quand une donnée est écrite sur un des périphériques, elle est automatiquement écrite sur le deuxième. Cela protège des pannes matérielles. Quand une des deux parties du mirroir cède, le volume devient alors linéaire, et reste accessible.
LVM supporte les volumes mirroré. Quand vous créez un volume mirroré, LVM s’assure que les données écrites sur un des volume physique soit bien répliqué sur un volume physique distinct. Avec LVM, on peut créer un volume logique avec plusieurs miroirs.
Un miroir LVM divise les données copier en régions qui généralement de taille 512KB. LVM maintient un petit log qui trace quel région est synchroniser avec quel miroir(s). Celui-ci peut être garder sur le disque et sera donc persistent aux redémarrage, ou bien il pourra être garder dans la RAM.
Figure 6: cas d’un volume mirroré avec log sur disque.
Les capacités des snapshots permettent la création d’images virtuelles d’un disque à un moment précis sans avoir à faire un interruption de service.
Quand un changement est fait sur le disque d’origine après qu’un snapshot soit pris, la fonctionnalité de celui-ci fait une copie de la nouvelle zone de données telle qu’elle était avant le changement de manière à pouvoir reconstituer l’état du périphérique.
Les snapshots LVM ne fonctionne pas à travers les cluster de LVM.
Parce que les snapshots copie seulement les zones de données qui on été changé après que le snapshot est été pris, la fonctionnalité requière un minimum d’espace disque. Par exemple, avec de rare mise à jour, 3 à 5% de la capacité d’origine est suffisante pour maintenir le snapshot.
Les copies des snapshots sont des copies virtuelles, et pas un système de backup pour le système. Les snapshots ne remplacement pas une procédure de backup.
Si un snapshot est saturé en terme de capacité, le snapshot est lâché. Cela pour être sur d’avoir assez d’espace pour le système de fichier. Il faut régulièrement surveiller la teille du snapshot. Les snapshots sont redimensionables, donc si vous avez la capacité de stockage, vous pouvez agrandir la taille du snapshot afin de prévenir la saturation de ceux-ci. A l’inverse si vos trouvez que la taille alloué au snapshot est trop importante, vous pouvez réduire la taille du volume afin de libérer de la place pour les autres volumes logiques.
Quand vous créez un volume de snapshot, le plein accès en lecture et en écriture à l’original reste possible. Si un morceau du snapshot est changé, celui-ci est marqué et ne sera jamais copié depuis le volume original.
Il y a plusieurs utilisation de la fonctionnalité de snapshot:
Fréquemment, un snapshot est pris quand vous avez besoin d’un backup d’un volume logique sans arrêter le système.
On peut exécuter la commande fdsk sur un snapshot pour vérifier l’intégrité et déterminer si le volume original a besoin d’une réparation.
Parce que les snapshots lise/écrive, vous pouvez tester des applications en production en prenant un snapshot et en recommençant les test, tout en laissant les vrais données intactes.
Vous pouvez utiliser la fonction de snapshot avec Xen afin de modifier une machine virtuelle, et de la restaurer en cas de besoin.
La création de ce type de volume dans un environnement de cluster est identique à la création d’un volume unique. Il n’y a pas de différences dans les commandes LVM, ou de l’interface d’administration disponible dans les distributions de Red Hat.
Pour la mise en place d’une infrastructure LVM en cluster, l’infrastructure du cluster doit être fonctionnel.
Installation d’une Debian GNU/Linux sur du raid1 soft avec md + lvm
Tout d’abord installer de manière traditionnelle la distribution Debian GNU/Linux sur l’un des deux disques.
256Mo me parait une valeur amplement suffisante :
debian:/boot# fdisk /dev/hdc The number of cylinders for this disk is set to 79656. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-79656, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-79656, default 79656): +128M Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. debian:/boot#
Attention s’assurer que vous pourrez créer une partition sur notre disque 1 faisant exactement la même taille. Ensuite créer cette partition de manière traditionnel avec fdisk par exemple.
debian:/boot# fdisk /dev/hdc
The number of cylinders for this disk is set to 79656.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)Command (m for help): p
Disk /dev/hdc: 41.1 GB, 41110142976 bytes
16 heads, 63 sectors/track, 79656 cylinders
Units = cylinders of 1008 * 512 = 516096 bytesDevice Boot Start End Blocks Id System
/dev/hdc1 1 249 125464+ 83 LinuxCommand (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (250-79656, default 250):
Using default value 250
Last cylinder or +size or +sizeM or +sizeK (250-79656, default 79656):
Using default value 79656Command (m for help): w
The partition table has been altered!Calling ioctl() to re-read partition table.
Syncing disks.
debian:/boot#
Nous allons commencer par créer un group raid dégradé avec seulement un disque.
debian:/boot# mdadm –create /dev/md1 –level 1 –raid-devices=2 /dev/hdc2 missing mdadm: array /dev/md1 started. debian:/boot# cat /proc/mdstat Personalities : [raid1] md1 : active raid1 hdc2[0] 40021056 blocks [2/1] [U_] md0 : active raid1 hda1[0] hdf1[1] 156288256 blocks [2/2] [UU] unused devices: <none> debian:/boot#
-> Installer lvm
debian:~# apt-get install lvm2
-> Créer le volume physique LVM
debian:~# pvcreate /dev/md1 Physical volume « /dev/md1″ successfully created
-> Créer le volume groupe LVM vg01 et y affecter le disque /dev/md1
debian:~# vgcreate -A n vg01 /dev/md1 Volume group « vg01″ successfully created
-> Créer les volumes logiques LVM
debian:/boot# lvcreate -A n -L 200M -n backup vg01 Logical volume « backup » created debian:/boot# lvcreate -A n -L 5G -n usr vg01 Logical volume « usr » created debian:/boot# lvcreate -A n -L 3G -n var vg01 Logical volume « var » created debian:/boot# lvcreate -A n -L 10G -n home vg01 Logical volume « home » created debian:/boot# lvcreate -A n -L 19G -n goinfre vg01 Logical volume « goinfre » created debian:/boot#
-> Informations à propos de vg01 et des volumes logiques
debian:~# vgdisplay -v vg00
Rebooter avec une knoppix ou autre live cd
# mkfs.ext3 /dev/md1 # mount /dev/md1 /mnt/new_root # cd /mnt/new_root # tar -C / -clspf – . | tar -xlspvf -
Faire la même chose pour :
-> Création de la partition qui doit être exactement de la même dimension que la première
debian:/mnt# sfdisk -d /dev/hdc | sfdisk /dev/hde debian:/mnt#
-> Ajout de la nouvelle partition à l’intérieur du group raid
debian:/mnt# mdadm -a /dev/md1 /dev/hde2 mdadm: hot added /dev/hde2 debian:/mnt#
-> La phase de reconstruction démarre
debian:/mnt# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 hdf1[2] hda1[0] 156288256 blocks [2/1] [U_] [>....................] recovery = 0.4% (759040/156288256) finish=44.3min speed=58387K/sec unused devices: <none> debian:/mnt#
-> La phase de reconstruction se termine
debian:/mnt# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 hdf1[1] hda1[0] 156288256 blocks [2/2] [UU] unused devices: <none> debian:/mnt#
Ce fichier permet de définir les différents groupes raid à activer.
Ci-dessous les différents scripts qui permettent d’activer les daemons mdadm et activer le raid :
debian:~# cat /etc/mdadm/mdadm.conf DEVICE /dev/hda1 /dev/hdf1 ARRAY /dev/md0 devices=/dev/hda1,/dev/hdf1 debian:~#
debian:~# mdadm –detail –scan >> /etc/mdadm/mdadm.conf
debian:~#
debian:~# cat /etc/mdadm/mdadm.conf
DEVICE /dev/hda1 /dev/hdc1
ARRAY /dev/md0 devices=/dev/hda1,/dev/hdc1
DEVICE /dev/hde* /dev/hdf*
ARRAY /dev/md1 devices=/dev/hde1,/dev/hdf1
ARRAY /dev/md2 devices=/dev/hde2,/dev/hdf2
ARRAY /dev/md3 devices=/dev/hde3,/dev/hdf3
ARRAY /dev/md4 devices=/dev/hde4,/dev/hdf4
debian:~#
Vous pouvez aussi déclarer vos disques avec le nom DEVICE et taper cette commande
LVM Administrator’s Guide – RED HAT
LVM ou comment changer d’idée sur le stockage de données sous Linux – Lionel Tricon
| lvmdiskscan | Cette commande donne un aperçu de tous les périphériques utilisables parLVM sur votre machine : liste les disques durs IDE et SCSI, les partitionsen Raid logiciel, les devices en loopback (loop device) et les devices bloc réseau (network block device) |
| pvscan | Lecture et affichage de tous les volumes physiques disponibles sur le système : utile pour localiser l’espace non utilisé |
| vgscan | Lecture et affichage de tous les volumes groupes présents sur le système |
| lvscan | Lecture et affichage de tous les volumes logiques présents sur le système |
| pvcreate | Initialisation d’une partition (ou périphérique compatible) pour pouvoir l’utiliser en volume physique : mise en place d’un descripteur de volumegroupe en début de partition
Les partitions doivent être de type 0×8e, à changer avec l’utilitaire « fdisk » |
| vgcreate | Création d’un volume groupe à partir de 1 ou plusieurs volumes physiques. Le VG sera accessible sous /dev/[VG] et peut être créé dans un mode linéaire (par défaut) ou un mode striping . Le volume est automatique activé |
| lvcreate | Création d’un volume logique dans un volume groupe. Le LV sera
accessible sous /dev/[VG]/[LV] |
| vgextend | Ajout d’un volume physique dans un volume groupe |
| vgreduce | Suppression d’un volume physique dans un volume groupe |
| lvextend | Extension de la taille d’un volume logique |
| lvreduce | Réduction de la taille d’un volume logique |
| pvdisplay | Affiche des informations liées à un volume physique |
| vgdisplay | Affiche des informations liées à un volume groupe |
| lvdisplay | Affiche des informations liées à un volume logique |
| lvremove | Supprime un volume logique |
| lvrename | Renomme un volume logique |
| vgremove | Supprime un volume groupe : vous devez vérifier qu’il n’y a pas de volume logique présent dans ce VG avant de le supprimer (le VG doit aussi être désactivé) |
| pvmove | Déplace les données d’un volume physique dans un autre volume physique
appartenant au même volume groupe. Est souvent utilisé pour pouvoir enlever un disque du gestionnaire de volume sans arrêt de service |
| vgchange | Active ou désactive un volume groupe |
Voici quelques stats sur la fréquentation du blog (mouhahah je vous flic tous).
On commence avec les OS :
Ensuite les navigateurs :
Ensuite la profondeurs de couleurs des écrans :
Puis les résolutions :
Et enfin la version de flash :
Selon Wikipedia,
Security-Enhanced Linux, abrégé SELinux, est un LSM (Linux security module), qui permet de définir une politique d’accès MAC (mandatory access control) aux éléments d’un système basé sur Linux. Initié par la NSA sur la base de travaux menés avec SCC et l’université d’Utah aux USA (prototypes DTMach, DTOS, projet FLASK), son architecture dissocie l’application de la politique d’accès et sa définition. Il permet notamment de classer les applications d’un système, en différents groupes, avec des niveaux d’accès plus fins. Il permet aussi d’attribuer un niveau de confidentialité pour l’accès à des objets systèmes, comme des descripteurs de fichier, selon un modèle de sécurité multi-niveaux MLS (Multi level Security). SELinux utilise le modèle Bell LaPadula avec Type enforcement de SCC pour l’intégrité. Il s’agit d’un logiciel libre, certaines parties étant sous licences GNU GPL ou BSD.
Sous un système Linux classique le contrôle d’accès est dit de type DAC Discretionary Access Control Ce type de controle d’accès vérifie simplement le propriétaire, le groupe, et les autres (les autres désignent tout ce qui ne fait pas partie du propriétaire et du groupe) en se basant sur le GID et l’UID.
Cependant, les limites de ce système de permission est facile à définir. Imaginons que nous avons un compte sur une système type Linux. Un compte utilisateur avec tout les permissions qui l’en découle. Lorsque ce compte user exécute un processus, le processus hérite des droits du compte user mais aussi de tous ses privilèges.
Transposons ce modèle dans un autre contexte. Je travaille avec un collègue sur un projet professionnelle, et il hérite donc de mes privilèges et droit dans l’environnement professionnel mais il hérite également du droit de rentrer chez moi, dormir dans mon lit etc … Inacceptable non ?
Il est donc impensable de donnez tout les droits en se basant uniquement sur l’UID et le GID. Il faut intégrer une notion fondamentale dans la gestion de sa sécurité : le contexte.
Voici un exemple de droit classique linux.
[root@CentOs www]# ls -l
total 48
drwxr-xr-x 2 root root 4096 jan 16 02:36 cgi-bin
drwxr-xr-x 3 root root 4096 mar 12 22:38 error
drwxr-xr-x 3 root root 4096 mar 16 12:19 html
drwxr-xr-x 3 root root 4096 mar 12 22:38 icons
drwxr-xr-x 14 root root 4096 mar 12 22:42 manual
drwxr-xr-x 2 webalizer root 4096 mar 14 04:02 usage
Et voici les droits SELinux
drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t cgi-bin
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t icons
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t manual
drwxr-xr-x webalizer root system_u:object_r:httpd_sys_content_t usage
Ce qui m’intéresse c’est httpd_sys_content_t. C’est a dire que le répertoire html est accessible par l’utilisateur apache uniquement lors du contexte d’utilisation du deamon httpd.
Un utilisateur usurpant ou détournant l’identité d’apache n’aura pas accès au répertoire html car il sortira du contexte d’utilisation du deamon httpd. Fabuleux non ?
Pour le reste, je vous laisse avec l’utilisation de la commande chcon pour modifier les contextes et les permissions de SELinux.
Donc.
man chcon
Salut a tous,
Quand on travaille avec des machines virtuelles, il y a un problème qui se présente rapidement. La taille de vos disques dur !!!
Pour cela, il faut compresser vos images disques.
7Zip est là pour vous aider.
Selon Wikipedia :
C’est un logiciel libre distribué sous licence LGPL, le code AES est sous licence BSD et le code unRAR est sous licence mixte (LGPL + des restrictions unRAR). Il est en compétition avec WinZip et WinRAR, qui sont des équivalents propriétaires de type partagiciel (ou shareware).
Le programme fonctionne en ligne de commande ou avec une interface graphique traduite dans 69 langues dont le français.
Il prend en charge les formats de fichier suivants :
Cependant le taux de compression est assez impressionnant.
Pour une image de 790 Mo on arrive à un fichier compressé de 119 Mo. Je pense que le ratio peut être intéressant d’un point de vue d’archivage des VM ou afin de backup.
Il est évident que l’on arrive à un tel ratio du fait du type de fichier à compressè. Sur un divx le gain est quasi nulle.
WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.
Planet Libre