Archives 2011
#Gnu/Linux
Initiation aux ACL
Tout le monde connait le système de droits utilisé sous linux, mais on connait moins les ACL qui permettent une gestion plus fine des droits sous linux. Pour résumer: Une ACL, ou Access Control List (en anglais : « liste de contrôle d'accès ») est, une liste de permissions sur un fichier, un répertoire ou une arborescence, ajoutée aux permissions « classiques »
Faisons un bref résumé des droits classiques unix/linux. Chaque fichier ne peut normalement indiquer des permissions que pour un seul utilisateur et un seul groupe, qui s'opposent à une unique catégorie correspondant à « tous les autres » (ou « le reste du monde »).
Par exemple:
drwxr-xr-x 2 laptop laptop 4096 2007-09-01 13:23 fichier
Ici quand on connait bien c'est très parlant:
on peut diviser les droits en d wxr r-x r-x
d = pour dire qu'il sagit d'un repertoire (si c'et un fichier on aurait -)
wxr pour le propriétaire
r-x pour le groupe
r-x pour les autres
r pour read, w pour write, x pour execution
on a donc le proprétaire en l'occurence laptop qui a tous les droit (rwx)
le groupe en l'occurence le groupe nommé laptop qui a les droits de lecture et d'execution (r-x)
les autres en l'occurence le reste du monde qui a les droits de lecture et d'execution (r-x)
Il est aussi utile de connaitre la nomenclature chiffre des droit linux:
r = 4 w= 2 x= 1
Pour chaque entité on peut alors donner des droits en chiffre
Par exemple :
laptop@laptop:~/test1$ ls -al total 12 drwxr-xr-x 3 laptop laptop 4096 2007-09-01 13:33 . drwxr-xr-x 27 laptop laptop 4096 2007-09-01 13:33 .. drwxr-xr-x 2 laptop laptop 4096 2007-09-01 13:33 test laptop@laptop:~/test1$ chmod 777 test/ laptop@laptop:~/test1$ ls -al total 12 drwxr-xr-x 3 laptop laptop 4096 2007-09-01 13:33 . drwxr-xr-x 27 laptop laptop 4096 2007-09-01 13:33 .. drwxrwxrwx 2 laptop laptop 4096 2007-09-01 13:33 test laptop@laptop:~/test1$ chmod 721 test/ laptop@laptop:~/test1$ ls -al total 12 drwxr-xr-x 3 laptop laptop 4096 2007-09-01 13:33 . drwxr-xr-x 27 laptop laptop 4096 2007-09-01 13:33 .. drwx-w---x 2 laptop laptop 4096 2007-09-01 13:33 test
Par addition des chiffres on donne les droits que l'on veut:
chmod 777 test :donnera rwx rwx rwx obtenu grace à : ( 4+2+1=7 4+2+1=7 4+2+1=7)
chmod 721 test :donnera rwx -w- --x obtenu grace à: (4+2+1=7 0+2+0=2 0+0+1=1)
Enfin bref on pourrait déjà parler des heures sur les droits de bases sous linux.
Interessons nous plus particulièrement aux ACL.
Déjà deux choses à indispensables:
1- Avoir le paquet ACL d'installé sur votre système.
2- Avoir un systeme de fichier monté avec l'option ACL
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 /dev/hda2 / ext3 defaults,acl,errors=remount-ro 0 1
Deux commandes fondamentales pour les ACL:
setfacl et getfacl
setfacl
Le nom de la commande se comprend set file's ACL (« régler l'ACL du fichier »). Elle possède de nombreuses options dont il convient de prendre connaissance en consultant la page de manuel (man setfacl). La commande fonctionne bien sûr aussi de manière récursive (option -R) :
On va modifier les droits grace à cette commande:
Un exemple concret:
L'utilisateur laptop possède des dossier dans son home qui de base on les permissions rwx r-x r-x (ou 755 rapellez vous)
A chaque repertoire crée il prend ces droits par défaut.
laptop@laptop:~/test1$ ls -al total 12 drwxr-xr-x 3 laptop laptop 4096 2007-09-01 13:53 . drwxr-xr-x 27 laptop laptop 4096 2007-09-01 13:33 .. drwxr-xr-x 2 laptop laptop 4096 2007-09-01 13:53 travail
Pourtant il absolument besoin que lui et l'utilisateur antony travaille conjointement dans le meme repertoire, il a besoin que lui et antony puisse ajouter des fichier dans ce repertoire.
De base c'est impossible puisque antony n'est pas le propriétaire et ne fait pas non plus partie du groupe laptop.
Donc pour l'intant seul laptop peut ecrire dans le répertoire travail.
Bien sur une solution serait de donner les droits d'écriture au groupe laptop et faire d'antony un membre de ce groupe.
Mais pas de chance laptop ne veut absolument pas que ce repertoire travail puisse etre modifié par certaine personne appartenant à ce groupe...
Comment faire ???
C'est la qu'interviennent les ACL
on va accorder a antony et seulement à lui les droits d'écriture dans ce repertoire.
laptop@laptop:~/test1$ setfacl -m u:antony:rwx travail/
On a maintenant:
laptop@laptop:~/test1$ ls -al total 16 drwxr-xr-x 3 laptop laptop 4096 2007-09-01 13:53 . drwxr-xr-x 27 laptop laptop 4096 2007-09-01 13:33 .. drwxrwxr-x+ 2 laptop laptop 4096 2007-09-01 13:53 travai
On voit qu'un + apparait montrant qu'une ACL est mise en place pour ce repertoire.
Pour en savoir plus on va utiliser la fameuse commande getfacl
drwxrwxr-x+ 2 laptop laptop 4096 2007-09-01 13:53 travail laptop@laptop:~/test1$ getfacl travail/ # file: travail # owner: laptop # group: laptop user::rwx user:antony:rwx group::r-x mask::rwx other::r-x
On voit bien que cette fois antony a tous les droits sur ce repertoire, il peut donc creer et modifier des fichier comme il veut.
Les principaux paramètres à connaître sont : * préfixes : o u: (droits pour un utilisateur, nommé ou désigné par son uid) ; o g: (droits pour un groupe, nommé ou désigné par son gid) ; o o: (droits pour other, le reste du monde) ; * permissions : elles sont codées dans l'ordre r, w et x ou X (ce dernier représentant, comme avec chmod, le droit d'entrée dans les répertoires ou celui d'exécution pour les fichiers qui ont déjà un marqueur x). On les remplace par - pour une interdiction explicite. Ne pas mentionner un droit revient aussi à une interdiction :
Dans l'exemple vu plus haut on a malheureusement une limitation:
En effet Antony, à le droit de creer des repertoire et des fichier dans le dossier travail, mais regardez le comportement:
laptop@laptop:~/test1$ ls travail laptop@laptop:~/test1$ cd travail/ laptop@laptop:~/test1/travail$ ls fic laptop@laptop:~/test1/travail$ rm -rf fic laptop@laptop:~/test1/travail$ touch fic1 laptop@laptop:~/test1/travail$ getfacl fic1 # file: fic1 # owner: laptop # group: laptop user::rw- group::r-- other::r--
On s'apercoit que si laptop creer un fichier dans le dossier travail, il n'herite pas des ACL su dossier parent :
D'ou probleme antony ne pourra pas modifier ce fichier:
Pour pallier à ce problême:
On peut modifier ce comportement en ajoutant, aux répertoires seulement, un attribut default, codé d:, qui se transmet à tous les
fichiers créés dans le répertoire après l'ajout de l'ACL par défaut. Par exemple, setfacl -m d:u:antony:rwx travail donne à luce les droits
de lecture et écriture (ainsi qu'« exécution » quand il s'agit de répertoires) pour tous les fichiers qui seront créés sous travail à partir
de ce moment, jusqu'à ce que cette ACL « par défaut » soit annulé ou remplacé.
exemple: de base :
laptop@laptop:~/test1$ getfacl travail/ # file: travail # owner: laptop # group: laptop user::rwx user:antony:rwx group::r-x mask::rwx other::r-x laptop@laptop:~/test1$ cd travail/ laptop@laptop:~/test1/travail$ getfacl fic1 # file: fic1 # owner: laptop # group: laptop user::rw- group::r-- other::r--
On utilise alors plutot la commande : setfacl -m d:u:antony:rwx travail/
laptop@laptop:~/test1$ setfacl -m d:u:antony:rwx travail/ laptop@laptop:~/test1$ getfacl travail/ # file: travail # owner: laptop # group: laptop user::rwx user:antony:rwx group::r-x mask::rwx other::r-x default:user::rwx default:user:antony:rwx default:group::r-x default:mask::rwx default:other::r-x laptop@laptop:~/test1/travail$ touch fic2 laptop@laptop:~/test1/travail$ getfacl fic2 # file: fic2 # owner: laptop # group: laptop user::rw- user:antony:rwx #effective:rw- group::r-x #effective:r-- mask::rw- other::r--
On voit bien que le nouveau fichier fic2 crée a bien hérité des droits de travail.
On ne peut pas parler des acl sans parler du mask:
Le masque est une synthèse des valeurs les plus permissives que possède un fichier doté d'une ACL. Les droits de l'utilisateur
fondamental ne sont cependant pas pris en compte. Le masque est calculé automatiquement :
L'intérêt du masque est de pouvoir limiter d'un coup toutes les permissions d'un fichier (étendues ou non), sauf celles du propriétaire ;
on utilise pour cela le préfixe m: suivi du droit maximal à accorder :
Exemple :
l
aptop@laptop:~/test1/travail$ setfacl -m u:antony:rwx fic1 laptop@laptop:~/test1/travail$ getfacl fic1 # file: fic1 # owner: laptop # group: laptop user::rw- user:antony:rwx group::r-- mask::rwx other::r--
On définit une acl sur fic1 pour antony afin qu'il est les droit rwx
laptop@laptop:~/test1/travail$ setfacl -m m:r fic1 laptop@laptop:~/test1/travail$ getfacl fic1 # file: fic1 # owner: laptop # group: laptop user::rw- user:antony:rwx #effective:r-- group::r-- mask::r-- other::r--
On voit bien qu'après avoir défini un mask (r--) Les droits effectif d'antony sur le fichier sont limités à ceux du mask.
Source: http://www.lea-linux.org
#Gnu/Linux
Mise en place d'un cluster haute disponibilité - Heartbeat - DRBD7
L'idée de se billet est de comprendre comment mettre en place un petit cluster de facon très simpliste. On part d'un cluster constitué de deux machines ou deux noeuds (node). Chaque machine va vérifier en permanence si l'autre répond toujours, elles vont en quelques sorte prendre le poul l'une et l'autre. Le but: si une machine crash pour une raison x, l'autre prend le relais de facon transparente. On accède au cluster par une adresse IP unique différentes des ip des nodes.
La surveillance des noeuds est rendue possible grace à heartbeat: il va se charger de surveiller les machines et d'appliquer une série de scripts définis par l'utilisateur si cela s'avère nécessaire.
Ne disposans de serveur à foisons, je suis parti de deux machines virtuelles hebergées sur un petit portable (pentium 4M 1.80GHz) sous Ubuntu dapper.
Node1:
<Maître / Primaire Installation neuve de Ubuntu server 6.06.1IP : 192.168.1.1 Hostname : node1 Disque de 3Go
Node2
Esclave/secondaire Installation neuve de Ubuntu server 6.06.1 IP : 192.168.1.2 Hostname : node2 Disque de 3Go
Nous avons donc nos deux nodes, fraichement installés et prêts a recevoir notre petit test.
Installation de heartbeat.
sudo apt-get install heartbeat
La configuration de heartbeat repose sur 3 principaux fichiers situés dans /etc/ha.d
ha.cf haresources authkeys
sudo vi /etc/ha.d/ha.cf
bcast eth0 debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 10 warntime 6 initdead 60 udpport 694 node node1 node node2 auto_failback on
Pour l'explication des options reprenons le Wiki sur http://doc.ubuntu-fr.org/heartbeat
bcast : indique l'interface réseau par laquelle on va effectuer la prise de pouls.
debugfile : indique le fichier de déboguage à utiliser.
logfile: indique le log d'activité à utiliser.
logfacility : indique que l'on utilise la facilité syslog en plus.
keepalive : indique le délai entre deux battements de pouls. Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
deadtime : indique le temps nécessaire avant de considérer un noeud comme étant mort. Ce temps est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
warntime : indique le délai avant d'envoyer un avertissement pour les pouls en retard. Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
initdead : indique un deadtime spécifique pour les configurations où le réseau met un certain temps à démarrer. initdead est normalement deux fois plus grand que deadtime (au minimum). Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
udpport : indique le port à utiliser pour la prise de pouls.
node : renseigne le nom des machines faisant partie du cluster. Ce nom doit être identique à celui retourné par la commande uname -n.
auto_failback : indique le comportement à adopter si le node maître revient dans le cluster. Si on met la valeur on, lorsque le node maître revient dans le cluster, tout est transféré sur ce dernier. Si on met la valeur off, les services continuent à tourner sur l'esclave même lorsque le maître revient dans le cluster.
Nous devons maintenant définir l'adresse IP du cluster. ceci se défini dans le fichier haresources
sudo vi /etc/ha.d/haresources
node1 IPaddr::192.168.1.10
Ici on définit donc que notre cluster utilisera l'ip 192.168.1.10 et surtout que se sera le node1 le master. (c'est sur ce noeud que vous tomberez toujours par défaut, si il n'est pas dead).
Le fichier authkeys permet aux nodes de cluster de s'identifier mutuellement.
sudo vi /etc/ha.d/authkeys
auth 2 1 md5 "cluster node test" 2 crc
Une fois le fichier édité, n'oubliez pas de le protéger en introduisant la commande :
sudo chmod 600 /etc/ha.d/authkeys
Voila la configuration de heartbeat est terminée, j'ai juste oublié de préciser que ces 3 fichiers de configurations doivent etre rigoureusement identiques sur les deux noeuds. N'oubliez pas de lancer heartbeat sur les deux noeuds:
sudo /etc/init.d/heartbeat start
On peut passer aux tests... Plusieurs facon de tester... La première très simple: installer un serveur ssh sur chaque noeud et tenter de s'y connecter en coupant un noeud ou l'autre..
Exemple je veux me connecter au cluster:
je me connecte donc en ssh à l'ip 192.168.1.10 on voit que le prompt est:
root@node1:~#
je stop le node1 en désactivant eth0 par exemple. Et j'essaye de me reconnecter sur l'ip du cluster: 192.168.1.10 et là au miracle regardez le prompt:
root@node2:~#
On est passé directement sur le noeud 2 de facon transparente.
Je me suis amusé aussi en imaginant que l'on heberge un site en haute dispo. J'ai donc installé apache sur les 2 noeuds. et fait une petite page html affichant node1 quand on se connecte en http sur node1 et node2 quand on se connecte sur node2.
Imaginons je suis un simple surfer sur le net et je veux visiter le site http://192.168.1.10 Je ne le sais pas mais c'est un site en haute dispo et pour l'instant tous les noeuds fonctionnent correctement. Ma page s'affiche :
Entre temps y le node 1 se met à fumer et part en carafe. Moi en tant que simple internaute je ne le sait pas et je veux acceder à mon site préféré ;-) Je me connecte donc en à http://192.168.1.10 sans savoir que le serveur principal à fumé. Qu'est ce qui s'affiche sur mon navigateur ?
Je suis passé de manière transparente sur le node2. Bon là bien sur j'ai mis des pages différentes pour qu'on voit bien sur quel noeuds on est connecté, mais dans la réalité on aurait un site identique sur les deux noeuds et qui se réplique en temps réèl l'un sur l'autre, en utilisant des technologies comme drbd par exemple (Raid1 par IP).
Bon, dans la vrai vie c'est plus compliqué que ca, les gros sites en géneral utilise des systeme de HA et d'équilibrage de charge... Mais ce systeme est utilisé très souvent à un moment ou à un autre dans l'infrastructure.
Mise en place d'un serveur de fichier en HA avec Heartbeat et drbd.
Je reprend ce billet pour essayer d'aller plus loin. Maintenant qu'on à deux noeuds en cluster, j'ai décider de tenter de monter un serveur de fichier aussi en ha.
Je plante le décors:
Même configuration que tout à l'heure, j'ai toujours mes deux machines virtuelles en cluster, je veux utiliser ce cluster en tant que serveur de fichier Samba haute dispo.
Pour cela je vais utiliser drbd. Il sagit d'un module qui permet de faire du raid1 par l'ip. Autrement dit grace à lui toutes les données ecrite sur un disque du noeud 1 seront automatiquement répliqué sur le noeud2.
Si le serveur maitre (node1) "tombe", je veux que cela soit transparent pour l'utilisateur et que mon serveur de fichier soit toujours disponible, ce qui est techniquement possible puisque drbd aura copié les données du noeud 1 sur le noeud2 et heartbeat aura détecté la panne et tout basculer sur node2.
J'ai longtemps galéré pour monter cette petite plateforme mais elle fonctionne au bout du compte.
Premiere chose à faire:
drbd est une ressources associée à un périphérique mode bloc (partition)
J'ai donc ajouté une partition de 1Go pour chacune de mes VM
Petit rappel, pour cela j'ai ajouter un disque virtuel pour chaque machine virtuelle sous vmware (je vous passe les explications: clic clic sur l'interface graphique).
On relance les VM et on tappe
fdisk -l
pour visualiser nos disques On s'apercoit qu'un nouveau disque est apparu (encore heureux) /dev/hdb
Je vais creer une partition primaire qui fait la totalité du disque hdb toujours grace à fdisk:
Lancer l'interface de partitionnement fdisk en ligne de commande, en précisant le disque à modifier :
root@node1:~# fdisk -l Disk /dev/hda: 3221 MB, 3221225472 bytes 255 heads, 63 sectors/track, 391 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 371 2980026 83 Linux /dev/hda2 372 391 160650 5 Extended /dev/hda5 372 391 160618+ 82 Linux swap / Solaris Disk /dev/hdb: 1073 MB, 1073741824 bytes 16 heads, 63 sectors/track, 2080 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Disk /dev/hdb doesn't contain a valid partition table
On créé alors la partion avec fdisk de la maniere suivante
root@node1:~# fdisk /dev/hdb Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. The number of cylinders for this disk is set to 2080. 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) Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-2080, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-2080, default 2080): Using default value 2080 Command (m for help): w Calling ioctl() to re-read partition table. Syncing disks.
On peu vérifier avec fdisk -l qu'on à bien notre nouvelle partition de 1Go /dev/hdb1
root@node1:~# fdisk -l Disk /dev/hda: 3221 MB, 3221225472 bytes 255 heads, 63 sectors/track, 391 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 371 2980026 83 Linux /dev/hda2 372 391 160650 5 Extended /dev/hda5 372 391 160618+ 82 Linux swap / Solaris Disk /dev/hdb: 1073 MB, 1073741824 bytes 16 heads, 63 sectors/track, 2080 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/hdb1 1 2080 1048288+ 83 Linux
Maintenant qu'on à creer notre partition on va s'attaquer au gros du travail: installer drbd
Tout d'abord on commence par installer la version du kernel Headers et build essentiel ( tout ce fait tout seul et le chemin d'installation se trouve dans /usr/src)#apt-get install linux-headers-$(uname -r) build-essentialPuis on installe DRBD source et utilitaire" attention la version des utilitaires doivent être de la même version que le noyau du module DRBD":Code:
#apt-get install drbd0.7-utils drbd0.7-module-sourceOn installe quelques paquets pour configurer le noyau et pouvoir appeler le module assistant du kernel pour installer le module DRBD
#apt-get install dpkg-dev kernel-package ncurses-devOn se rend dans le répertoire source pour détarer les sources DRBD
#cd /usr/src #tar xfzv drbd0.7.tar.gzIl est nécessaire d'installer le paquet contenant la version 3.4 de GCC
#apt-get install gcc-3.4On se rend dans le dossier du kernel-headers
#cd /usr/src/linux-headers-2.6.17-2-686et on lance le module-assistant pour intégrer le module DRBD dans le noyau courant:
#module-assistant
Une fois module-assistant lancé, allez dans SELECT, puis sélectionnez le module drbd0.7 et onTermine en faisant un BUILD puis un INSTALL.
Le module est prêt à être lancé. Utilisez la commande modprobe pour le charger# modprobe drbdEnfin, utilisez la commande lsmod pour verifier que le module est bien chargé
# lsmod | grep drbdon doit voir
drbd 127412 1
DRBD étant installé, nous allons le configurer
Tout se passe dans le fichier:/etc/drbd.conf
Voici mon fichier drbd.conf à mettre sur les deux noeuds :
vi etc/drbd.conf
resource datas { protocol C; incon-degr-cmd "halt -f"; startup { wfc-timeout 240; degr-wfc-timeout 240;} disk { on-io-error panic; } syncer { rate 10M; group 1; al-extents 130; } on node1 { device /dev/drbd0; disk /dev/hdb1; address 192.168.1.1:7788; meta-disk internal; } on node2 { device /dev/drbd0; disk /dev/hdb1; address 192.168.1.2:7788; meta-disk internal; Une ressources que j'appelle datas Je défini mes deux noeuds avec leur device virtuel /dev/drbd0 et leur device physique /dev/hdb1
dès à présent on peu redemmarer le daemon drbd et voir que les deux disques /dev/hdb1 sur node1 et /dev/hdb1 su node 2 se synchronisent. sur chaque noeud on lance drbd/etc/init.d/drbd startOn défini le node1 comme le noeud primaire pour drbd :
root@node1:~# drbdsetup /dev/drbd0 primary --do-what-I-sayOn voit la synchro se dérouler
oot@node1:~# /etc/init.d/drbd status Unknown command 'sh-nop'. drbd driver loaded OK; device status: version: 0.7.15 (api:77/proto:74) SVN Revision: 2020 build by root@node1, 2007-08-21 17:16:52 0: cs:SyncTarget st:Secondary/Secondary ld:Inconsistent ns:0 nr:111024 dw:111024 dr:0 al:0 bm:118 lo:728 pe:235 ua:728 ap:0 [==>.................] sync'ed: 12.1% (809104/917216)K finish: 0:16:51 speed: 508 (2,700) K/secOn peut visualiser à tout moment l'état de drbd en faisant:
cat /proc/drbd
root@node1:~# cat /proc/drbd version: 0.7.15 (api:77/proto:74) SVN Revision: 2020 build by root@node1, 2007-08-21 17:16:52 0: cs:Connected st:Primary/Secondary ld:Consistent ns:8 nr:0 dw:4 dr:21 al:0 bm:1 lo:0 pe:0 ua:0 ap:0ici on voit bien que node 1 est le serveur primaire qu'il est synchronisé avec node2 qui est secondaire. et leur disque /dev/drbd0 est opérationnel.
On peut maintenant formater le device /dev/drbd0 Comme le tout est synchronisé, il suffit de le faire sur un seul noeud.
root@node1:~# mkfs.ext3 /dev/drbd0On peut maintenant creer un dossier nommé drbd0 et monter le périphérique virtuel /dev/drbd0 sur ce dossier. Sur node1 ca donne:
root@node1:/# mkdir drbd0 root@node1:/# mount /dev/drbd0 /drbd0/ root@node1:/# ls bin cdrom drbd etc initrd initrd.img.old lost+found mnt proc sbin sys usr vmlinuz boot dev drbd0 home initrd.img lib media opt root srv tmp var vmlinuz.old root@node1:/# cd /drbd0/ root@node1:/drbd0# ls lost+foundPour vous prouver mes dires, je crée un dossier sur /drbd0/
root@node1:/drbd0# touch test1 root@node1:/drbd0# ls test1 root@node1:/drbd0# touch test2 root@node1:/drbd0# ls test1 test2Bon à présent démontons /drbd0 sur le node 1 et montons le sur le node2
root@node1:/# umount /drbd0 root@node1:/# cd drbd0/ root@node1:/drbd0# lsMaintenant sur le node2
root@node2:~# drbdsetup /dev/drbd0 primary --do-what-I-say
root@node2:~# mount /dev/drbd0 /drbd0 root@node2:~# cd /drbd0/ root@node2:/drbd0# ls test1 test2
Les fichiers qui ont été crées depuis le node1 ont bien été répliqué sur le node2 Notre DRBD fonctionne correctement.
Nous avons oublier de modifier une chose importante: le comportement de hearbeat envers DRBD si l'un des deux noeuds tombe: Pour cela nous allons modifier /etc/ha.d/haresourcesroot@node2:/# vi /etc/ha.d/haresources
node1 drbddisk::datas Filesystem::/dev/drbd0::/drbd0::ext3 IPaddr::192.168.1.10
On dit donc à heartbeat:
Le node1 sera le maitre
Si un des noeuds tombe : remonter sur l'autre noeud la ressource DRBD nommée datas correspondant au périphérique /dev/drbd0 dans le dossier /drbd0
L'ip du cluster est 192.168.1.10
Résumons:
Dans l'état actuel, nous avons un cluster former de 2 noeuds: node1 et node2.
Grace à DRBD tout ce qui sera écris sur le périphérique virtuel /dev/drbd0 est répliquer en temps réèl sur chaque noeud, puisque /dev/drbd0 correspond au périphérique physique /dev/hdb1 de chaque noeud.
Grace à heartbeat si node1 tombe, toutes les ressources sont basculées sur node2. et plus particulièrement: /dev/drbd0 est remonté sur node2 dans /drbd0. Quand node1 reviens, il repasse master, /dev/drbd0 est démonté du node2 et remondé sur node1.
La preuve par l'exemple: J'ai eut l'idée d'un banal serveur de fichier sous samba: j'ai installé un serveur samba sur chaque node: je ne vous décrirai pas l'installation d'un serveur Samba, qui se retrouve sur moultes tuto: La seule chose interessante est la fin du fichier de conf de samba:vi /etc/samba/smb.conf
...................................... [PARTAGE] path = /drbd0/ available = yes browseable = yes public = yes writable = yes
Et oui on s'en serait douté j'ai partagé directement /drbd0/ précisément ou /dev/drbd0 est monté.
Après avoir fait cette configuration sur les deux noeuds, j'ai tranquillment fait des test à partir d'un troisième poste sous windows Je me suis mis à la place d'un simple utilisateur windows qui veut accéder à ses fichiers sur un serveur de fichier. sans savoir qu'on a mis en place de la HA sur ce cluster.
je sais que mon serveur de fichier à l'ip 192.168.1.10 Donc je vais voir les partages sur cette IP
Mes fichiers sont là c'est cool !!! ;-)
l'utilisateur ne le sait pas, mais node1 brule:
Je vais simuler simplement en éteignant node1 :-)
On essaye d'acceder une seconde fois au cluster
En tant que simple utilisateur je retrouve mes fichiers identiques avant que node1 ne brule
Maintenant allons plus loin: Je créee un nouveau dossier dans les partages (nous sommes tjs sur node2 car node1 à fumé)
Entre temps le gentil technicien à réparé node1 et l'a relancé: Moi en tant qu'utilisateur je veux encore acceder au serveur de fichier Je vais donc sur le serveur de fichier (ip du cluster):
tout se passe bien mes fichiers sont là et même celui que j'ai crée avant l'incendie ;-) L'utilisateur s'en fiche, mais le node1 est remonté et est repassé en primaire, /dev/drbd0 à été remonté automatiquement sur ce noeud... drbd à bien joué son role avant que node1 ne tombe, les fichiers on été répliqués en temps réèls sur node2
C'est transparent pour l'utilisateur !!!!
Ce qui interessant de constater c'est que quand je relance node1 aprè l'avoir réparé et sauver du feu tout rebascule sur lui
On peut d'ailleurs constaté en se connectant directement sur node1 par la console, qu'il est bien actif et que /dev/drbd0 à bien été remonté
root@node1:~# mount /dev/hda1 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw) /sys on /sys type sysfs (rw) varrun on /var/run type tmpfs (rw) varlock on /var/lock type tmpfs (rw) udev on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) devshm on /dev/shm type tmpfs (rw) /dev/drbd0 on /drbd0 type ext3 (rw) root@node1:~# cd /drbd0/ root@node1:/drbd0# ls Nouveau Document Microsoft Word.doc test1 test2 root@node1:/drbd0#
Nous avons donc bien réussi à mettre en place de la ha sur un cluster de deux noeuds, grace à heartbeat et drbd.
Cette solution n'est bien sur pas parfaite, puisque l'idéal serait de ne plus avoir de primary/secondary, mais du primary/primary
En effet je recherche en ce moment comment faire la meme chose mais en actif/actif, c'est à dire que les deux noeuds pourraient monter et écrire en même temps sur /dev/drbd0. J'imagine que c'est possible en utilisant des systeme de fichier cluster tels que lustre, ocfs2, gfs etc...
Alors si vous avez réussi à monter une telle architecture contactez moi ;-)
#Gnu/Linux
Se connecter en SSH sans mot de passe
Il est souvent utile de pouvoir se connecter sur un serveur en SSH mais sans avoir à tapper de mot de passe. Notamment lors de l'utilisation de scripts (upload ou download en scp sur un serveur)
J'utilise la génération d'une paire clés privé et publique sur la machine cliente que j'incrémente dans authorized_key du serveur.
Sur le client ( machine qui veut se connecter au serveur sans avoir à tapper le mot de passe) Génération d'une paire de clé :
$ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/gerard/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
key fingerprint is: 6f:c5:86:c7:67:69:02:1a:e4:a9:20:e6:16:13:5d:e5 username@host
Cette opération à crée deux clés: id_dsa (clé privée) id_dsa.pub (clé publique)
Le but du jeux est maintenant d'envoyer la clé publique sur le serveur :
$ cd ~/.ssh $ scp id_dsa.pub username@serveur:
Apposez le fichier copié `id_dsa.pub` au fichier `authorized_keys` (qui se trouve dans le répertoire ~/.ssh) (si il n'existe pas il sera crée automatiquement).
$ cat id_dsa.pub >> .ssh/authorized_keys
Vous pouvez maintenant effacer la clé plublique que vous venez de transferer, puisqu'elle à été incrementée dans le fichier authorized_keys
$ rm id_dsa.pub $ exit
Dès à présent vous pouvez vous connecter en SSH au serveur sans avoir à entrer de mot de passe. et ceca de manière relativement sécurisé (utilisation de clés publique et privée)
#Gnu/Linux
Initiation rapide au LVM : Gerer votre système de fichiers. testé sous Ubuntu 6.06 / Suse 10
En général quand on parle d'espace disque, on pense à partition primaire, etendue, lecteur logique etc... Chez soi, quand on manque d'espace disque on rajoute un hdd et on crée une nouvelle partition... Avec LVM (Logical Volume Manager) on s'affranchie de cette limite, il va permettre de voir l'ensemble des disque comme des volumes extensible a volonté. On pourra par exemple regrouper 10 disques dur physique en un seul volume et vu par le système comme une seule et meme partition. Et cette dernière sera extensible volonté.
En général quand on parle d'espace disque, on pense à partition primaire, etendue, lecteur logique etc... Chez soi, quand on manque d'espace disque on rajoute un hdd et on crée une nouvelle partition... Avec LVM (Logical Volume Manager) on s'affranchie de cette limite, il va permettre de voir l'ensemble des disque comme des volumes extensible a volonté. On pourra par exemple regrouper 10 disques dur physique en un seul volume et vu par le système comme une seule et meme partition. Et cette dernière sera extensible volonté.
Le système de LVM insère des sous-couches entre la partition de disque et votre système de fichier (là où sont vos données). Ces sous-couches vont vous permettre de modifier dynamiquement la taille des systèmes de fichier, sans mettre en péril vos données. Ainsi vous pourrez ajouter, enlever de l'espace disque d'un filesystem à la volée, rajouter un système de fichier... sans modification de la table des partitions.
Ces deux couches se nomment : le "Volume Group (Abréviation : VG)" et le "Logical Volume (ou LV)".
A un "Volume Group", nous affecterons des partitions de disque. Chaque disque ou partition de disque affecté à un VG lui est exclusivement réservé. Il est impossible d'affecter un même disque à plusieurs VG.
Dans chaque VG, nous créerons plusieurs LV. Chaque LV sera alors formaté et monté dans notre arborescence pour y être utilisé par l'utilisateur final. Quand nous formatons un LV, nous créons en fait un système de fichier (fs) : c'est cette couche que vous utilisez lorsque vous effectuez l'opération de montage.
Un petit schéma :
Partition(s) de disque
|> Volume Group |> Logicals Volumes |> système de fichiers
Au lieu de :
Une partition de disque
|>un système de fichier
Ces couches intermédiaires vont donc permettre une meilleure mobilité de nos systèmes de fichiers. ( cf:http://sluce.developpez.com/lvm/ )
Tout dabord assurer vous que vous disposez du paquet lvm2
Pour la suite, je m'appuie sur le magnifique outil Webmin ainsi que la ligne de commande, on aurait put tout faire en ligne de commande mais webmin permet de faire plus rapidement certaine chose...
Je beneficie d'un pc portable et deux clés USB, je me suis dit pourquoi ne pas crée des LVM avec ces clé puisqu'elles sont vues comme des disques à part entière par le système.
Deux clés USB: /dev/sdd1 et /dev/sdg1
Passons par Webmin /hardware/LVM
Nous avons à présent: un VG (volume group) qui est test_vg ( comprenant un disque physique) un LG (logical volume)
Nous allons creer le systeme de fichier sur ce logical volume
sles101:~ # mkfs.ext3 /dev/test_vg/lv_usb mke2fs 1.38 (30-Jun-2005) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 124416 inodes, 248832 blocks 12441 blocks (5.00%) reserved for the super user First data block=0 8 block groups 32768 blocks per group, 32768 fragments per group 15552 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 33 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
On peut maintenant monter notre file system
sles101:~ # mount /dev/test_vg/lv_usb /media/usb1
On creer des dossiers à l'intérieur
sles101:~ # cd /media/usb1/ sles101:/media/usb1 # ls lost+found sles101:/media/usb1 # mkdir test1 test2 test3 sles101:/media/usb1 # ls lost+found test1 test2 test3
Tout fonctionne à merveille, mais imaginez que vous travaillez sur ce volume, et que la place vient a manquer. En temps normal on ajouterai un disque, on creerai le systeme de fichier et on serait obliger de travailler sur l'autre disque... en plus d'avoir un nouveau disque dans le systeme cela peut etre problematique. Imaginez uneb ase de donnée sur un disque qui n'a plus d'espace, il faudrait déplacer toute la base sur un nouveau média
Avec le LVM ce probleme n'existe plus, il va nous permettre d'integrer un nouveau disque physique dans notre volume existant et ainsi etendre le systeme sur la nouvelle partition logique .
Pour le système cela va etre transparent, il va voir le meme disque mais avec une plus grande capacité.
Rappel: on a pour l'instant un volume test_vg comprenant un disque (1 clé usb 1go), ce volume contient une partition logique lv_usb avec un systeme de fichier qui s'étend sur tout le volume logique.
On veut maintenant ajouter un nouveau disque (une nouvelle clé usb de 1go) l'integrer à test_vg, et etendre lv_usb sur ce nouveau média ainsi que son système de fichier.
Ajoutons le nouveau disque au volume test_vg
Retour sur webmin pour ajouter le disque:
Retour sur la ligne de commande pour etendre notre logical volue et donc notre file system.
Pour l'instant on à seulement un file system de 1000Mo. on va l'etendre à 1500Mo
sles101:/media/usb1 # lvextend -L+500M /dev/test_vg/lv_usb Extending logical volume lv_usb to 1.44 GB Logical volume lv_usb successfully resized
On peut maintenant monter notre FS
sles101:/media # mount /dev/test_vg/lv_usb /media/usb1/ sles101:/media # cd /media/usb1/ sles101:/media/usb1 # ls lost+found test1 test2 test3
On peut voir que notre volume logique est plus grand et que les données sont intactes.
sles101:/media/usb2 # fdisk /dev/test_vg/lv_usb Command (m for help): p Disk /dev/test_vg/lv_usb: 1543 MB, 1543503872 bytes 255 heads, 63 sectors/track, 187 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes
Cela se vérifie bien sur sous webmin:
#Gnu/Linux
Sécuriser un DNS BIND avec les views
Ce billet explique comment éviter que votre serveur DNS serve de relay DNS.
En général la manière classique d'éviter que votre dns réponde au demande autre que celle relative à votre domaine est d'implementer la commande allow-recusion en la limitant sur une ACL
acl lan { localhost; 192.168.0.0/16; }; options { allow-transfer { none; }; allow-query { lan;}; allow-recursion { lan;}; }; Mais si vous faites des tests plus avancés, vous vous rendez vite compte que votre DNS répond à des requetes extérieures mais pour résoudre des noms qui n'appartiennent pas à votre domaine. En entreprise ce n'est pas acceptable. En fait votre DNS ne résoud pas tous les noms mais seulement qui sont déjà dans son cache local.... La commande vu plus haut n'empêche pas l'accès au cache du serveur DNS. Si l'attaquant réussit à peupler ce cache (par exemple en envoyant un courrier à une machine utilisant légitimement ce serveur récursif), il pourra quand même mener son attaque. BIND 9.4 (pas encore publié à ce jour) aura une nouvelle option allow-query-cache qui résoudra ce problème. Avec cette option, une configuration raisonnable sera : allow-recursion {mynetworks;}; allow-query-cache {mynetworks;}; // Surtout ne pas oublier celui-ci. Mais en attendant cette nouvelle version on ne peut pas se permettre de laisser notre cache DNS ouvert à tout le monde... Pour résoudre ce probleme on va creer des views. La commande view dansbind permet de determiner qui aura le droit de visu sur les différentes zone de notre DNS. Le but sera donc de creer une ACL qui comprendra tous les hotes de notre réseau local ( par exemple LAN) et une autre view pour tous les autres, qui n'auront accès qu'a la zone qui gere votre nom de domaine... Votre DNS ne répondra qu'au requetes qui concerne votre nom de domaine et aucune autre. pour cela je vous montre mon fichier de conf vi /etc/bind/named.conf acl lan { localhost; 192.168.0.0/16; }; // logic to all top level domains, and to the root domain. An exception list // should be specified, including "MUSEUM" and "DE", and any other top level // domains from whom undelegated responses are expected and trusted. // root-delegation-only exclude { "DE"; "MUSEUM"; }; #include "/etc/bind/named.conf.local"; view interne { match-clients { lan; }; recursion yes; zone "." { type hint; file "/etc/bind/db.root"; }; zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; zone "info16.fr" { type master; file "/etc/bind/db.mondomaine.fr"; }; zone "22.151.91.in-addr.arpa" { type master; file "/etc/bind/db.mondomaine.fr.inv"; }; }; view externe { match-clients { any; }; recursion no; zone "mondomaine.fr" { type master; file "/etc/bind/db.mondomaine.fr"; }; zone "31.121.91.in-addr.arpa" { type master; file "/etc/bind/db.mondomaine.fr.inv"; }; }; Les étapes importantes, # Creer une acl acl lan { localhost; 192.168.0.0/16; }; # creer les views en définissant, qui a droit d'utiliser la view et quelle zone sont visible dans cette view. view interne { match-clients { lan; }; recursion yes; zone "." { type hint; file "/etc/bind/db.root"; }; zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; zone "info16.fr" { type master; file "/etc/bind/db.mondomaine.fr"; }; zone "22.151.91.in-addr.arpa" { type master; file "/etc/bind/db.mondomaine.fr.inv"; }; }; view externe { match-clients { any; }; recursion no; zone "mondomaine.fr" { type master; file "/etc/bind/db.mondomaine.fr"; }; zone "31.121.91.in-addr.arpa" { type master; file "/etc/bind/db.mondomaine.fr.inv"; }; }; Testons la différence entre notre DNS sécurisé et un DNS mal configuré inet:/var/log # nslookup > server cxd15.com Default server: cxd15.com Address: 200.200.134.52#53 > www.free.fr Server: cxd15.com Address: 200.200.134.52#53 Non-authoritative answer: Name: www.free.fr Address: 212.27.48.10
Dans cet exemple on voit bien que la dns de la société (fictive) cxd15, donne l'ip correspondant à www.free.fr
Maintenant en utilisant notre serveur a partir de l'exterieur.
@@
inetgw:~ # nslookup > server ns.info.fr Default server: ns.info.fr Address: 91.100.30.206#53 > www.free.fr Server: ns.info16.fr Address: 91.100.30.206#53 Non-authoritative answer: *** Can't find www.free.fr: No answer@@
Mais bien sur si on fait la meme requete sur notre serveur, mais à partir de notre réseau local.
@@
root@serveur:~# nslookup > www.free.fr Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: www.free.fr Address: 212.27.48.10
@@
On voit bien que notre DNS est sécurisé et ne répond aux requetes récursives que lorsque c'est son propre réseau local (défini dans l'ACL lan) qui l'interroge.
PS: Les ip que j'ai utilisée sont fictives ainsi que leur nom de domaines associés.