L'essentiel
Ceci est un essai de publication de documents avec TWiki. Le but final est de migrer les documentations publiques de RTFM ici, puis d'éventuellement référencer, voire intégrer, ces documents de base dans des cours. Un peu de pub parasite CRIL, faut-il déplacer cela dans une homepage professionnelle? dans CRIL ? split? éviter les redites avec Wikipedia?
Le but serait d'utiliser cette information de manière à éviter les redites (FAQ) ou les duplications (cours).
standard | Ce terme signifie qu'il s'agit d'un système, d'un logiciel, d'un protocole ou d'un procédé qui est recommandé |
deb http://packages.cril.ch/cril/debian/packages/ sarge cril
/etc/environment
) LANG=C LC_CTYPE=fr_CH.ISO-8859-1 LC_COLLATE=fr_CH.ISO-8859-1
La mise en place de RAID1 ou de LVM est faite via le test standard de réinstallation automatisé DR CRIL (en même temps que le test obligatoire d'intégrité de reconstruction RAID1).
nom | contenu | cas démarrage RAID1 |
---|---|---|
/dev/hda1 | /boot | /dev/md0 |
/dev/hda2 | swap | /dev/md1 |
/dev/hda3 | / | /dev/md2 |
D'autres partitions peuvent exister: p.ex. une grande /dev/hda4
comme LVM, dans laquelle sont définis des volumes
logiques pour les données (/data
) et la zone non sauvegardée (/scratch
), ou une grande partition RAID1 pour
un filesystem ou un LVM.
Il faut savoir que les CD d'installation standard peuvent nommer les périphériques différemment. Par exemple,
/dev/hda
peut être /dev/ide/host0/bus0/target0/lun0/disc
et /dev/hda1
alors
/dev/ide/host0/bus0/target0/lun0/part1
. Le plus simple est d'utiliser la fonction de completion du shell (touche TAB).
Le CD standard DR CRIL n'a pas ce problème, le nommage est cohérent avec le standard ci-dessus.
En SCSI, le même principe de partitionnement est maintenu.
interface réseau | dispositif matériel (p.ex. carte PCI, carte insérable PCMCIA, chip intégré sur une carte-mère: carte Ethernet, WLAN/WIFI (802.11)) ou logiciel (interface loopback virtuelle liant cet ordinateur à lui-même, VPN ou tunnels, liaisons via modem ou port série, etc. Ces interfaces sont nommées suivant le systèmes d'exploitation, par exemple eth0, wlan0, lo, tun0 et ppp0 |
adresse IP | adresse unique d'une interface sur Internet, ou, dans le cas d'utilisation d'adresses privées (p.ex. dans la plage 192.168.0.0/16 ou d'autres plages sous 172 et sous 10) unique dans le réseau administratif considéré. Ces adresses sont toujours allouées dans le sous-réseau concerné. Elles sont soit configurées manuellement, soit attribuées automatiquement par un serveur DHCP. Dans ce cas, elles sont soit dynamiques (dans une plage d'adresses dédiée), soit assignées statiquement par une table de correspondance mettant en jeu l'adresse MAC de la carte physique. |
adresse MAC | Adresse définie par le fabricant de la carte physique d'accès au réseau, qui peut servir à assigner des adresses IP de manière fixe, ou à filtrer -- de manière relativement peu sûre -- l'accès à un réseau (p.ex. WLAN/WIFI) |
routeur par défaut ou passerelle | routeur, sur un sous-réseau TCP/IP, qui sait acheminer les datagrammes plus loin dans le réseau (hors du sous-réseau),: on parle aussi de gateway |
sous-réseau | découpage logique d'un réseau en plages d'adresses définies par un masque de bits (subnet) |
netmask | masque de sous-réseau: définit la grandeur de la plage de sous-réseau considérée |
broadcast | diffusion: définit l'adresse à utiliser pour l'envoi d'un datagramme à toutes les interfaces d'un sous-réseau |
@@A définir plus précisément, car ces concepts sont centraux: interface, ordinateur (un ordinateur peut avoir plusieurs interfaces, de réseaux physiques identiques ou incompatibles, de réseaux logiques souvent différents), ainsi qu'un exemple de calcul de netmask et de présentation d'adresse CIDR, et la précision sur les divers sous-réseaux d'adresses privées. A mon avis des liens à Wikipedia peuvent suffire.
Nous allons tester cela durant cette procédure.
En exécutant cette procédure vous acceptez les conditions générales CRIL. Veuillez vérifier que votre responsable système ou département informatique soit au courant de notre intervention!
telnet login.alphanet.ch 22
Vous devriez avoir quelque chose comme suit à l'écran:
Trying login.alphanet.ch... Connected to login.alphanet.ch Escape character is '^]'. SSH-1.99-OpenSSH_3.4p1 Debian 1:3.4p1-1
Si cela fonctionne, il vous est possible de contacter n'importe quel service d'une machine externe (dans ce cas une machine chez moi) depuis les machines internes, ce qui est une bonne chose. Tapez plusieurs fois la touche RETURN pour sortir du programme.
Si cela ne fonctionne pas, installez le package telnet
ou netcat
, ou passez
directement à la section suivante si vous pensez que le firewall
ne posera pas de problème, en particulier si l'erreur est:
bash: telnet: command not found
Vous pouvez aussi essayer 46.140.72.222
à la place de login.alphanet.ch
si vous suspectez un
problème de DNS interne.
Assurez-vous qu'un serveur SSH local est activé et fonctionne (p.ex. ssh localhost -l user
),
avec user
un utilisateur existant avec un mot de passe valide.
Ensuite, faites la commande suivante. Elle active la possibilité, uniquement
depuis une de mes machines (login.alphanet.ch
), d'accéder via protocole sécurisé SSH à
votre ordinateur. J'aurai besoin d'un compte sur votre machine (p.ex. user
ci-dessus)
(utilisateur normal pour commencer, voire root
si nécessaire).
ssh -R 2222:localhost:22 callback@login.alphanet.ch
(dès que vous aurez tué ce processus, vous couperez l'accès extérieur
sécurisé de login.alphanet.ch
)
Appelez-moi dès que vous avez le prompt mot de passe (Password:
), et je vous
l'indiquerai puis procéderai à l'intervention.
Techniquement, la commande ci-dessus autorise la machine login.alphanet.ch à se connecter à votre machine, port 22 (serveur SSH) via la connexion SSH déjà établie (tunnel inverse).
Une manière simple est la suivante: je me loggue sur votre machine via le tunnel inverse établi ci-dessus depuis login.alphanet.ch, sur le compte schaefer (qui doit être le compte sur lequel
vous avez une session ouverture):
ssh -p 2222 -L 5900:localhost:5900 schaefer@localhost
Je configure l'accès à l'écran de votre machine: export DISPLAY=:0
Je lance ensuite x11vnc -storepasswd
, puis x11vnc -usepw
Je peux maintenant me connecter à votre écran: vncviewer localhost:5900
.
Si nécessaire, depuis une autre machine que login: ssh -L 5900:localhost:5900 login.alphanet.ch
Ensuite j'efface le mot de passe: rm .vnc/passwd
.
Id: acces_distant,v 1.2 2005/01/26 20:38:44 schaefer Exp
Le principe: un seul port TCP (aucun en UDP) du routeur ADSL (qui peut très bien être du matériel embarqué bon marché du commerce) est redirigé sur un serveur standard du réseau interne, via NAT/PAT statique. Sur celui-ci le service SSH est activé (port 22). Idéalement, on s'assurera que seules certaines adresses sont autorisées à accéder au port indiqué (donc adresses statiques). Si l'interdiction n'est pas possible/trop lourde, on peut le faire du côté du serveur standard (moins sûr)
Dans l'exemple, on décide que le port 22 du firewall sera PATé statiquement sur le port 22 de la machine 192.168.1.10, ceci sans aucune restriction (depuis tout Internet, sinon restreignez!)
Une alternative serait de choisir un numéro de port externe (du firewall) non connu, ce qui limiterait les logs d'attaque, sans pour autant offrir une véritable sécurité supplémentaire.
Il est en général une bonne idée de restreindre l'accès à SSH à un certain nombre d'adresse IP statiques, de manière à ne pas avoir une mise à jour critique sur le service SSH en cas de problèmes de sécurité, ou pour diminuer le nombre d'attaques automatisées et donc d'entrées de log.
Attention: seul un compte DynDNS gratuit par entité/personne.
Comme test il est recommandé d'introduire une adresse IP incorrect dans la configuration chez dyndns.org, de tester
qu'elle est incorrecte via p.ex. la commande host
, puis de redémarrer le routeur ADSL et de constater que le
DNS change.
Il peut s'agit d'un PC standard, d'un PC embarqué, d'un routeur ADSL sous GNU/Linux, ou d'un MLS firewall (PC bas de gamme sans disque, avec CD-ROM et floppy, sécurisé).
Des VPNs clients peuvent alors être mis en place avec le logiciel multiplateforme OpenVPN?.
Il n'est jamais recommandé de mettre en place les solutions embarquées VPN du commerce (lourdes, complexes, peu sécurisées, problèmes d'interopérabilité) en particulier en IPsec.
L'avantage est clair: tcpdump s'utilise également sur des systèmes plus simples dépourvus d'interface graphique ou lorsque le fonctionnement ne doit pas nécessairement être interactif.
tcpdump -i eth0 -s 0 -w /tmp/capture -n
, puis, sur un système local sous système standard ou non, lancer ethereal /tmp/capture
après avoir transféré le fichier, p.ex. avec scp
.
init single
(S) et donc d'éviter beaucoup d'opérations de préparation du
niveau 2 (voir aussi /etc/inittab
) et donc de problèmes potentiels.
On active ce mode en ajoutant à la ligne de commande de LILO ou de GRUB le paramètre single
. Par exemple,
avec LILO, taper SHIFT au prompt de démarrage, puis TAB pour lister les images. L'image standard s'appelle tout
simplement linux
: pour obtenir le mode single user, tapez simplement linux single
.
Dans ce mode, les systèmes de fichiers sont en général montés correctement. Par contre, il vous faudra très vraisemblablement le mot de passe root!
En cas de problème, il est possible de spécifier un autre block-device pour /
, p.ex. dans le cas standard
linux single root=/dev/hda3
(ou /dev/md2
). Ce commentaire est valable pour tous les modes qui suivent.
Si cela ne fonctionne pas, il faut utiliser un mode plus bas niveau, le mode init=/bin/sh.
Le paramètre à ajouter au démarrage est linux init=/bin/sh
. Familiarisez-vous au clavier US à l'avance.
Au prompt du shell bash root (#
), vous devez commencer par remonter /
en lecture-écriture et monter les
autres systèmes de fichiers, si nécessaire
mount / -o remount,rw mount /boot # si vraiment nécessaire: mount -a
Si cela ne fonctionne toujours pas, il faut utiliser un autre média de démarrage.
/
et /boot
sont réellement nécessaires à ce stade.
On se bornera alors à démarrer avec un média de démarrage, par exemple le CD DR CRIL, ou un CD d'installation (aller jusqu'au partitionnement, sans le faire, puis commutez sur la console 2 (ALT-F2) et tapez RETURN pour un shell), puis à faire
mkdir -p /target mount /dev/hda3 /target mount /dev/hda1 /target/boot
Une fois le système démarré et les systèmes de fichiers accessibles, on peut modifier (avec les outils du média de
démarrage, ou ceux du système lui-même via chroot /target
) p.ex. le fichier /etc/fstab
, ou /etc/shadow
,
ou lancer la commande passwd
, reconfigurer le démarrage, etc
Avant de redémarrer, il faut démonter les systèmes de fichiers. Le cas de /
est spécial: si vous l'avez remonté rw
, remontez
le ro
(read-only).
En supposant LILO, il faut modifier /etc/lilo.conf
, changer boot
(où l'on stocke le démarrage, souvent /dev/hda
p.ex.)
et root
(souvent /dev/hda3
ou /dev/md2
en cas de démarrage en RAID1).
Il faut ensuite relancer LILO, p.ex. avec lilo -r /target
(version de LILO du média de démarrage) ou chroot /target /sbin/lilo
.
Notez que si le système démarre en RAID1, il faut réinstaller deux fois LILO (une fois avec boot=/dev/hda
et une fois
avec boot=/dev/hdc
si l'on veut un démarrage véritablement RAID1).
Dans tous les cas une adaptation de /etc/fstab
peut être nécessaire si les noms ont changé (p.ex. passage de RAID1 à
disque physique, etc).
Quelque chose comme:
chroot /target # suppose /target/boot aussi monté grub-install hd0 # si ne fonctionne pas, utiliser ce qui suit grub # ceci lance l'interface shell grub root (hd0,0) # /dev/hda1 p.ex., /boot setup hd0 # installation dans le MBR quit exit # sortir du chroot # démonter, etc.
Si une des questions a une réponse positive, la sécurité du système ne peut être assurée.
On peut résoudre le problème d'une ou plusieurs manières:
Il est clair que faire ainsi augmente le risque de non disponibilité du système (déni de service, DoS?). La réparation ou même le redémarrage de la machine nécessitera une intervention en site. Il s'agit ici d'évaluer les avantages et les inconvénients du niveau de sécurité choisi, sans sombrer dans la paranoïa ni une confiance excessive: les solutions les plus simples sont souvent les meilleures.
Dans tous les cas, le système dupliqué ne peut pas être utilisé tel quel. Il faut encore adapter au minimum son adresse IP (/etc/network/interfaces) avant de le démarrer. De plus, il se peut qu'il faille reconfigurer le démarrage si le disque est déplacé de bus physique ou pour d'autres raisons.
conv=noerror,sync
est utile si le disque comporte des erreurs matérielles. Si le mode DMA n'est pas activé
(voir hdparm -v /dev/hda /dev/hdc
, puis hdparm -d 1 /dev/hd[ac]
si le mode DMA est connu comme fonctionnel),
la copie peut prendre beaucoup de temps. De toute manière la copie prendra plus de temps que via une copie intelligente
(voir plus bas), surtout si le disque n'est pas utilisé sur toute sa capacité.
Par contre, la copie brute permet également de dupliquer des OS non standard très facilement, si nécessaire et légal.
L'outil debuge2fs
permet de récupérer certaines données, éventuellement. Une autre idée serait d'utiliser p.ex.
dump/restore (jamais essayé).
L'utilitaire gpart
permet de scanner un disque entier et de retrouver, éventuellement, les partitions et types de filesystems
qu'il contenait.
tar --directory=/target --numeric-owner -xpf FICHIER
, en supposant que tous les systèmes de fichiers ont été montés (p.ex. /target, /target/boot, /target/data, /target/scratch, etc; mkdir
si nécessaire!) et que le chemin au fichier de sauvegarde est FICHIER
.
Ensuite, reconfigurez le démarrage.
/etc/fstab
, /etc/network/interfaces
) ainsi que la sortie de certaines commandes comme fdisk -l
memtest86
)
Si c'est juste le démarrage qui pose problème, p.ex. dans un array RAID avec un BIOS qui ne supporte pas le démarrage sur le 2e disque, on peut utiliser un autre média de démarrage.
Solutions simples
cp /boot/vmlinuz /dev/fd0 rdev /dev/fd0 /dev/md2 # si / est /dev/md2
Solutions plus générales
apt-get install simple-scripts syslinux # ce qui suit pas forcément sous root # adapter le chemin de vmlinuz, initrd et le périphérique pour / /usr/lib/simple-scripts/scripts/make-boot-cd /boot/vmlinuz /boot/initrd /dev/hda3 /tmp/cd.iso # graver cd.iso, p.ex. via /usr/lib/simple-scripts/scripts/record_cds.sh, sous root
Quelques conseils pour éviter le repartitionnement manuel:
parted
montrée ici.
root@ubuntu:~# fdisk -l /dev/sda Disk /dev/sda: 120.0 GB, 120060444672 bytes 255 heads, 63 sectors/track, 14596 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 14317 115001271 83 Linux /dev/sda2 14318 14596 2241067+ 5 Extended /dev/sda5 14318 14596 2241036 82 Linux swap / Solaris
On voit que le plus simple est de:
root@ubuntu:~# fdisk /dev/sda [ ... ] Command (m for help): d Partition number (1-5): 5 Command (m for help): d Partition number (1-5): 2 Command (m for help): w
évt. revérifier avec fdisk -l /dev/sda
, voire redémarrer.
Ensuite repartitionner /dev/sda1
:
root@ubuntu:~# parted /dev/sda [ ... ] (parted) p Disk geometry for /dev/sda: 0kB - 120GB Disk label type: msdos Number Start End Size Type File system Flags 1 32kB 118GB 118GB primary ext3 boot (parted) p 1 Minor: 1 Flags: boot File System: ext2 Size: 118GB (98%) Minimum size: 4264MB (4%) Maximum size: 120GB (100%) (parted) resize 1 Start? [32kB]? End? [118GB]? 20GB
L'opération dure un certain temps.
Il est bien de redémarrer, à ce stade, en particulier si une mise en garde a été affichée par fdisk
à l'écriture
de la table des partitions.
Par acquit de conscience:
root@ubuntu:~# e2fsck -f /dev/sda1 e2fsck 1.38 (30-Jun-2005) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/sda1: 87246/2457600 files (0.8% non-contiguous), 666722/4883752 blocks
Il faut ici:
root@ubuntu:~# fdisk /dev/sda [ ... ] Command (m for help): n Command action e extended p primary partition (1-4) e Partition number (1-4): 2 First cylinder (2433-14596, default 2433): Using default value 2433 Last cylinder or +size or +sizeM or +sizeK (2433-14596, default 14596): Using default value 14596
Création de la partition de swap (du bon type 0x82):
Command (m for help): n Command action l logical (5 or over) p primary partition (1-4) l First cylinder (2433-14596, default 2433): Using default value 2433 Last cylinder or +size or +sizeM or +sizeK (2433-14596, default 14596): +2G Command (m for help): t Partition number (1-5): 5 Hex code (type L to list codes): 82 Changed system type of partition 5 to 82 (Linux swap / Solaris)
Création de la nouvelle partition:
Command (m for help): n Command action l logical (5 or over) p primary partition (1-4) l First cylinder (2677-14596, default 2677): Using default value 2677 Last cylinder or +size or +sizeM or +sizeK (2677-14596, default 14596): Using default value 14596
Mémorisation
Command (m for help): w
Il est bien de redémarrer, à ce stade, en particulier si une mise en garde a été affichée par fdisk
à l'écriture
de la table des partitions.
mkswap /dev/sda5
/etc/fstab
Dans notre cas, aucune partition n'ayant changé de numéro, aucun changement n'est donc nécessaire.
La nouvelle partition /dev/sda6 est donc disponible pour travail.
Dans notre cas, le démarrage étant fait via grub
et la partition /
n'ayant pas changé de numéro ou de disque, aucune reconfiguration n'est
nécessaire.
Dans le cas de LILO, il faudrait relancer LILO.
(On parle ici du cache embarqué dans les disques-durs, et non pas du cache automatique Linux utilisant le maximum de mémoire libre).
Le cache disque en lecture ne gêne que rarement. Le cache disque en écriture est gênant pour des raisons de cohérence des données en cas de coupure de courant ou de crash immédiat (panne franche). Il faut le désactiver dans le BIOS et/ou, pour plus de sécurité, dans Linux (hdparm -W 0 /dev/sd[a-z], à chaque démarrage, automatisable via /etc/default/hdparm). En effet, le cache disque en écriture répond simplement "OK" sans faire l'opération immédiatement! Cela peut être catastrophique en cas de panne.
Les disques actuels sont très performants sans cache disque en écriture dans la mesure où le command-queuing est activée. En SCSI, c'est le cas depuis très, très longtemps. En IDE c'est impossible. En SATA, il faut en général passer le chipset en mode AHCI dans le BIOS, puis vérifier que le command queuing est activé (le problème peut aussi être sur certains disques-durs), par exemple:
virtual:~# grep NCQ /var/log/dmesg [ 2.041800] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA [ 2.041804] ata4.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA [ 2.043176] ata2.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA [ 2.043180] ata3.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
Le command queueing permet de lancer plusieurs commandes de lectures et d'écritures simultanées sur un disque-dur. Le contrôleur du disque-dur va alors réorganiser les commandes de la manière la plus efficace et, du point de vue de la performance, cela remplace avantageusement un cache disque et augmente même les performances au-delà.
Si le command-queueing est impossible sur une configuration donnée, il est aussi possible de laisser le cache-disque et d'activer les write barriers, qui devraient permettre de limiter les dégâts, en particulier en présence de journalisation, en cas de panne franche.
Outils
En ce qui concerne le code, celui-ci est chargé et déchargé à la demande: l'exécution d'un programme consiste simplement au mapping du fichier exécutable et des objets partagés nécessaires dans l'espace mémoire du processus, à charge de l'exécution proprement dite de générer des fautes de pages, qui conduiront au chargement du code réellement exécuté.
Cependant, tout a changé avec le kernel 2.4. Dès ce moment-là, le sous-système de gestion de la mémoire pouvait non seulement ralentir le système en cas de swap insuffisant (probablement en jettant des pages READ/EXECUTE, comme du `text' -- le code des programmes trop vite, de manière à augmenter le buffer cache, pages qui devront être relues des exécutables plus tard, ralentissant significativement la performance), mais aussi provoquer la mort d'un processus qui a trop alloué de mémoire -- ou un autre au hasard...
On conseille donc aujourd'hui également la règle swap = 2 x RAM
sur un système GNU/Linux. Jusqu'à environ 2 GB,
disons.
Linux reconnaît deux types de zones de swap, qui peuvent être déclarées dans /etc/fstab
ou manuellement activées
et désactivées.
dd if=/dev/zero of=mon_fichier_de_swap bs=1024k count=500
, ici 500 MB, marqués avec mkswap mon_fichier_de_swap
et activés avec swapon mon_fichier_de_swap
.
Plusieurs zones de swap sont possibles et une priorité peut être définie. Il faut se rappeler cependant que chaque zone de swap diminuera, en cas d'utilisation effective, d'autant le MTBF du système (on peut le considérer comme du RAID 0 sur de la mémoire ...). D'où l'idée d'utiliser du swap par-dessus le RAID 1 (miroir).
La première partition de swap peut également être utilisée pour le save to disk des portables, si elle est de taille suffisante et du bon type.
Impact éventuel de la journalisation et du VFS
La plupart des fs journalisés ne journalisent que les métadatas (sauf une
option rarement utilisée de ext3), soit les structures de données du
système de fichiers. Le fichier de swap ne grossissant jamais
(taille définie une fois pour toute via dd
avant mkswap
; donc pas
d'extension de la liste des blocs du fichiers ou des pointeurs indirects), et les
modifications d'inode (méta-données) étant inexistante (même si noatime pas configuré)
dans ce cas précis (comme les fichiers mmap(2)és), à mon avis, la
journalisation n'a aucun impact dans ce cas, en particulier pas à l'usage.
Il y aura certes un peu de performance perdue à travers les couches du VFS, mais rien en comparaison avec le facteur 1'000? 10'000? de temps d'accès au disque-dur.
"Fragmentation", non-contiguité et fragmentation BSD/FFS
La fragmentation (sens Microsoft) c'est le fait que les blocs de données d'un fichier (et, sur UNIX, également les contenus des répertoires) soient non contigus. UNIX parle plutôt de "*non-contiguité*". Plus clair, plus simple, utilisez ce mot svp! C'est comme le mauvais mot formatage pour création de systèmes de fichiers; ou bien sûr le mot cluster utilisé pour tout et rien dire.
fsck.* reporte la "fragmentation" (sens Microsoft) comme "non contiguous", ce qui est plus clair.
ext3 évite la non-contiguité grâce à la préallocation de blocs de données (unique à Linux) et à la répartition de données sur les groupes de cylindres (commun à BSD/FFS). Cette stratégie élimine complètement la fragmentation sauf dans des cas particuliers (p.ex. remplissage du disque-dur à plus de 90% -- d'où la réserve préconfigurée à la création du système de fichiers). Il y a un article de Roberto DI COSMO (la secrétaire efficace) @@@ lien?
Originellement, le but d'augmenter la taille de bloc atomique du filesystem (p.ex. de 1k à 4k) était double:
Microsoft a poussé cette stratégie de manière relativement stupide, avec des tailles de blocs (ce que Microsoft
appelle incorrectement un cluster ...) dépassant les 64k. Cela signifiait alors que créer 1'000 fichiers de 1 kilobyte
n'utiliserait pas 1 Mégabytes mais bien 1000 x 64k
, soit 64 Mégabytes!
UNIX (BSD/FFS) a eu l'idée de fragmenter un bloc atomique du filesystem pour y placer plusieurs petits fichiers, augmentant ainsi l'efficacité de stockage des données, au prix d'une faible dégradation de performance éventuelle. ext3 ne supporte pas cette optimisation, mais comme la taille de bloc est assez faible (4k) et que les fichiers systèmes ont grossi avec le temps, avec les disques-dur, cela n'est plus autant critique.
Impact de la non-contiguité ("fragmentation")
Comme le fichier de swap est créé assez tôt ou lorsque le filesystem n'est pas encore rempli à plus de 90%, on peut supposer que la non-contiguité est inexistante, d'où aucun impact de la "fragmentation". En conséquence du fait que les méta-données ne changent pas aucune non-contiguité subséquente ne peut en résulter.
Par contre, il y aura de toute manière groupage par groupes de cylindres, ce que fait ext3 dès que la taille d'un fichier dépasse une certaine valeur. Vu le principe que `les données sont locales', cela ne devrait pas poser de problèmes particuliers.
Un swap actif est donc une très mauvaise chose.
Par contre, on doit supposer que l'accès en dehors de l'OS reste possible à de vieilles données éventuellement migrées
dans le swap. Par exemple des clés privées de chiffrement GPG ou SSL, des mots de passe, etc. La solution POSIX est d'utiliser l'appel système mlock(2)
sur les zones de mémoires concernées, bloquant celles-ci en mémoire physique. Comme cette
fonctionnalité peut être détournée de son objectif initial (déni de service, DoS?), elle est privilégiée. Cela signifie que les
programmes utilisateurs qui en font usage doivent obtenir ce privilège, par exemple via le mécanisme de SUID, ou les
capabilities si celles-si sont configurées dans le système. Dès le kernel 2.6.9 cependant, cet appel système n'est plus
privilégié, et des limites, via ulimit(2)
et la commande interne du shell ulimit
permet de configurer cela.
A voir, Ubuntu 6.06 LTS n'implémente aucune limite préconfigurée, ce qui à mon avis est un BUG, j'en ai informé Ubuntu (pas de manière stricte, cependant) le 2006-10-18:
Since 2.6.9, mlock(2) changed: now, every process is allowed to force pages to stay in physical memory, until the barrier set through ulimit(2) (or the bash internal command ulimit) are met. The previous behaviour was to allow mlock(2) only to root or properly capable processes (lcap(8)). This has an advantage: end-user programs no longer need a SUID root security risk (such as GPG; etc). However, at least on my version of Ubuntu (6.06 LTS), there is no preconfiguration for that item. I would set it to half of the system memory and document it somewhere. One can regret that the kernel developpers pass so heavy changes in a kind-of-stable release (I prefer to stick to 2.4 on servers or systems which need to be reliably managed myself for now), but it happened ... Where can I suggest changes to ulimit policies like this ?
L'autre utilisation (autre que la sécurité décrite ici) de mlock(2)
est pour les applications à temps de réaction critique,
qui se combine souvent à la modification de la politique de scheduling à un scheduling temps réel, en dehors du round-robin
à temps partagé et quantas d'UNIX.
Une autre méthode d'assurer globalement la sécurité est d'écraser (dd if=/dev/zero of=/dev/hdaX
) les données. Cela prend
beaucoup de temps à l'extinction de la machine et n'est pas sûr du point de vue de l'analyse forensique. L'alternative la plus
sûre quoique la plus lente est de passer via un loop device chiffré:
LODEV=`losetup -f` \ && dd if=/dev/zero of=f bs=1024k count=100 \ && losetup --nohashpass --pass-fd 3 3</dev/random -e des $LODEV f \ && mkswap $LODEV \ && swapon $LODEV
@@@ non testé. Il y-a-t-il mieux que des? 3des?
L'allocation de mémoire sur les systèmes Linux `actuels' est assez simple: on dit ok, c'est bon (appel système brk(2)), tant que ce qui est demandé peut tenir dans l'espace mémoire privé du processus (de 2 à 3 GB suivant le mapping mémoire choisi: s'il y a plus de 1 GB de mémoire dans la machine, environ, disons 2 GB par processus sur plateforme standard pour simplifier).
La zone de mémoire allouée est simplement mmap(2)ée dans l'espace mémoire du processus, et un gestionnaire (handler) de faute de page spécifique y est associé, via le MMU. Cet handler est appelé en cas d'accès. En lecture, il générera des NULs (ASCII zéro), en écriture il allouera réellement la page et de désinstallera comme handler.
Cela ne signifie pas du tout qu'il y a assez de mémoire logique (RAM + swap), voire physique (RAM) pour allouer effectivement les données. Il y a comme pour les réservations de voyages en avion overbooking, ou overcommitting -- la pénalité de ce compromis est la mort pour le processus qui n'a pas eu de chance.
Cette allocation réelle peut provoquer:
/proc/sys/vm/
malloc(3)
), voir kill -l
, pour indiquer la condition plus de mémoire (Out of memory, OOM) au processus, signal qui peut être traité par le processus (ce que fait p.ex. OpenOffice), ou provoque la terminaison du processus (ainsi qu'un message dans le kernel log)
Un petit exemple:
/* Le programme ne fonctionnera peut-être pas comme prévu, tout dépend * comment la libc gère l'allocation, je n'ai pas essayé récemment! * A vos risques et périls. */ #include <stdlib.h> #include <stdio.h> int main(int argc, char **argv) { unsigned long int bytes_allocated = 0; unsigned char *addr; while ((addr = malloc(4096))) { bytes_allocated += 4096; #ifdef TOUCH addr[0] = 1; /* touch */ #endif /* TOUCH */ } printf("allocated: %lu bytes.\n", bytes_allocated); return 0; }
En 2.4, ce programme devrait, si TOUCH n'est pas défini, allouer jusqu'à 2 ou 3 GB de mémoire (donc éventuellement plus que de mémoire physique installée) puis finir par une erreur (ENOMEM), par défaut: l'address space du processus a été totalement mangé, les tables MMU ont été allouées, mais personne n'a jamais réellement accédé aux pages concernées: elles n'ont pas été véritablement allouées.
Si l'on définit TOUCH, dans ce cas, ce programme va manger toute la mémoire libre, attaquer les caches, les buffers, déplacer en swap des données, jeter des pages de code, etc, puis il finira probablement par se faire tuer, ou malencontreusement tuer un gros processus autre (eh oui), voir dans certains rares cas causer d'autres problèmes, suivant le(s) processus touché(s).
Le problème est que l'allocation réelle de la page qui était de trop (la dernière bouchée, le dernier petit chocolat alors que les dents du fond baignent déjà) ne fonctionne pas.
Cette allocation réelle correspond en fait au premier accès en écriture à la page.
Mais le processus qui a voulu allouer une page n'est pas forcément celui qui a demandé beaucoup de mémoire. De plus, il est trop tard pour `retourner une erreur' ou autre: il faut envoyer un signal POSIX pour indiquer cette condition, qui peut être éventuellement traitée. Sinon, le processus est terminé.
Mais comment résoudre ce problème ?
ulimit
: cf ulimit -a
, via un wrapper de lancement de l'application: on peut aussi limiter globalement (et pas par application ou utilisateur/login) pour le système, ou faire le contraire (limiter et élever la limite pour certaines applications)
Oui, il est possible de revenir à un comportement plus sain (ou du moins plus prévisible), mais plus dispendieux, de préallocation réelle des pages.
En 2.4 on cherche
find /proc -name '*overcomm*'
et on lit la manpage (man 5 proc
) qui concerne cela.
Malheureusement -- à ma connaissance -- supprimer complètement l'overcommit est impossible en 2.4. On peut simplement donner des indications au système dans le sens voulu. En 2.4, on a donc intérêt d'ajouter également une stratégie reposant sur une limitation des dégâts.
Je laisse des personnes plus expérimentées compléter pour cette nouvelle version.
Une astuce pour bien dimensionner la mémoire sur un serveur standard:
sar
, vmstat 5
dans un screen, etc) si le swap est actif en permanence ou souvent.
S'il y a des pages dans les swap, même beaucoup, style 200-500MB mais que ces pages ne sont jamais cherchées du swap (swap-in, si dans =vmstat 5=), ou ne sont jamais créées, sinon au début du fonctionnement du système, pas besoin de rajouter de la RAM.
vgdisplay -a
) et vous allez pouvoir maintenant l'attribuer -- ou vous avez rajouté des volumes physiques, de préférence en RAIDx (x >= 1), ou encore vous avez réduit l'espace utilisé par un volume logique.
Vous allez pouvoir augmenter la taille d'un système de fichiers sans downtime ou avec un downtime minimal.
La diminution de taille n'est pas traitée ici (elle fonctionne de manière simple aussi avec e2fsadm).
e2fsadm
demande:
ATTENTION: ne vous trompez pas de version de LVM à l'installation. Notamment, l'OS non standard Fedora Core 5 utilise par défaut une version trop récente de LVM, compatible dans une certaine mesure avec l'environnement standard, mais incompatible avec e2fsadm et non testé.
e2fsadm va tout d'abord redimensionner le volume logique à la dimension demandée, puis redimensionner le système de fichiers via resize2fs. Pour ce faire, le système de fichiers doit être démonté -- et sera vérifié! Cela peut prendre un temps non négligeable.
La synchronisation peut s'appliquer sur différents objets:
La synchronisation de données peut être implémentée de différentes manières, suivant la granularité de synchronisation (délai, contrôle de version éventuel, etc)
ou, plus simplement:
Il n'y a pas besoin ici de contrôle de version ou de gestion de conflits, vu que les portables ne sont pas utilisés en même temps. S'ils le sont, l'utilisateur est responsable d'éviter les problèmes manuellement (p.ex. en ne consultant pas les mails sur les deux portables, ou en utilisant p.ex. IMAP, et en acceptant que le système ou les données modifiées d'un des portables soient écrasés par l'autre).
Il peut y avoir des données qui ne sont pas communes, elles seront exclues de la synchronisation.
rsync
. Le principe est que rsync va
transférer uniquement les données qui ont changé, à chaque lancement de la commande. On devra choisir dans quelle
direction le transfert doit se faire.
Pour simplifier, le principe ici sera que c'est celui qui lance la commande de synchronisation qui sera écrasé par l'autre machine. Il faut donc utiliser les deux laptops en même temps le temps de la synchronisation, faite de préférence en console texte.
On n'utilisera pas rsync
directement, mais un package d'abstraction CRIL.
voyager# apt-get install simple-data-rsync
Prendre un exemple de configuration, et le modifier:
voyager# cp /usr/share/doc/simple-data-rsync/etc-backups-rotate.conf.sample /etc/backups-rotate.conf.VOYAGER voyager# chmod 444 /etc/backups-rotate.conf.VOYAGER voyager# vi etc/backups-rotate.conf.VOYAGER
Une partie de la modification consiste à indiquer le répertoire (qui sera /
, ici il ne s'agit pas d'une sauvegarde incrémentale, le
cas typique de mise en oeuvre de simple-data-rsync
).
Optionnellement, un script permettant de lancer l'opération de manière simplifiée:
voyager# cat > /root/scripts/rsync_reliant.sh <<EOF #! /bin/sh /usr/lib/simple-data-rsync/scripts/backup_rsync.sh reliant 10800 /etc/backups-rotate.conf.VOYAGER EOF voyager# chmod 700 /root/scripts/rsync_reliant.sh
Faire de même symétriquement sur la deuxième machine reliant.
Nous avons mentionné qu'il faut exclure certains fichiers. Les candidats sont:
/etc/X11/XF86Config
ou /etc/X11/xorg.conf
/etc/hosts
, /etc/hostname
, voire /etc/mailname
/etc/modules
/boot/grub/menu.lst
et éventuellement les images kernel si elles sont différentes (alors attention aux mises à jour de sécurité qui ne seront plus automatiquement synchronisées!)
Il suffit d'adapter le fichier /etc/backups-rotate.conf.VOYAGER
et de configurer la variable
ADDITIONAL_EXCLUDES
(séparer les noms de fichiers ou de répertoire par des /, ne pas
utiliser de métacaractères).
Ensuite, synchroniser voyager à reliant ainsi:
voyager# /root/scripts/rsync_reliant.sh
On peut utiliser la fonction md5sum (par exemple du package simple-scripts
), ou carrément le package
simple-data-sync
(sans le r!) pour comparer également les non fichiers et les permissions UNIX.
Une solution qui peut, dans une certaine mesure, gérer les conflits est le logiciel unison
. L'autre possibilité -- si on se
bornait aux données utilisateurs et éventuellement aux configurations systèmes -- serait le contrôle de version. On s'assurerait
alors que le jeu de données, lorsqu'on quitte un portable, serait =commit=té sur un serveur CVS.
Il ne s'agit pas ici de load-balancing
, mais bien de master-slave
, ou fail-over
.
ssh
et ntp
. Pour ce faire, une modification des scripts de démarrage doit être effectuée.
On y lancera régulièrement à distance une procédure de synchronisation, du maître, via cron
, avec un délai
maximum (timeout). Cette synchronisation exclut quelques fichiers, qui sont copiés spécialement (en zone d'attente).
Un mail sera envoyé si le système esclave ne fonctionne plus.
En cas de panne du serveur principal, le serveur principal (maître) doit être arrêté manuellement. Le serveur esclave est activé comme maître (manuellement, en activant quelques fichiers de configuration), notamment en reprenant son adresse IP.
Une sauvegarde réelle est faite de manière différente à ce qui est décrit ici.
On installe le package fail-over-support
ainsi que les packages recommandés de synchronisation. Suivre
/usr/share/doc/fail-over-support/README.
Dans ce qui suit le terme hébergé réfère à la machine virtuelle et hôte au système englobant.
Une description plus complète peut être lue à l'URL http://fr.wikipedia.org/wiki/Virtualisation
Voici quelques fonctionnalités, qui sont ou non présentes
Même si ce document cite le GULL, je ne suis plus membre de cette association ni ne soutiens la manière dont elle est gérée.