Linux RAID1 soft, changement d’un disque

Lorsque l’on utilise une solution de sauvegarde, on est toujours inquite le jour où il faut mettre en oeuvre la restauration … c’est bien se qui m’est arrivé le jour où l’un de mes disques RAID1 à grillé et qu’il a fallu le changer puis restaurer le RAID1. Et bien en 1 mot (mais personne n’en doutait) le RAID1 soft sous linux ca marche nickel !

Détails de l’opération :

  • Retrait du disque defectueux et retour au fournisseur
  • Le système fonctionne parfaitement sur son second disque le temps que le disque en SAV revienne
  • Backup des données (on sait jamais)
  • Reinstallation du second disque dans la machine
  • Synchro du RAID1
  • Retour au mode normal

Bref super ! Pour ce qui est des quelques commandes magiques à utiliser :
sfdisk –dump /dev/sdx | sfdisk /dev/sdy Permet de cloner la table des partitions du disque x sur le disque y.
mdadm /dev/mdx -a /dev/sdy Permet d’ordonner la resynchronisation du disque que l’on vient d’ajouter en le remontant dans l’ensemble RAID1.

La progression de la reconsruction du raid peut être suivie en consultant /proc/mdstat

Tomcat, problème de JVM_LIBDIR

Par defaut la config ne semble pas cohérente du coup j’ai eu des messages de ce style … “cp=/%20JVM_LIBDIR%20/usr/lib64/jvm-exports/java-1.5.0-sun-1.5.0%20does%20not%20exist%20or%20is%20not%20a%20directory” ou encore “error: JVM_LIBDIR /usr/lib64/jvm-exports/java-1.5.0-sun-1.5.0 does not exist or is not a directory”
Pour s’en sortir j’ai créé un lien symbolique dans /usr/lib64/jvm-exports/ de “java-1.5.0-sun-1.5.0 pointant” vers “java”.
Il faut ensuite redemmarer tomcat et ca fonctionne.

Raid1 soft avec Asus P5B-VM sous opensuse 10.1

Après avoir realisé une installation de ma suse 10.1 sur un disque configuré en RAID1 soft, j’ai eu la désagreable surprise de trouver un kernel panic au boot du style : VFS: Cannot open root device “…” or unknown-block(…,…)

Il semble qu’a ce moment là du demarrage le disque md0 ne soit pas encore bien monté (problème de module sans doute)… la solution simple pour s’en sortir est de préciser dans les paramètre du boot que root n’est pas sur /dev/md0 mais sur /dev/sda1 par exemple … ce qui ne change pas fondammentalement grand chose si ce n’est qu’en cas de defaillance de sda1, il faudra penser à preciser sdb1 pour que ca boote.

La procédure n’empeche absoluement pas / d’etre monté sur md0 une fois la machine bootée. Il faudra modifier les parametres de grub dans /boot/grub/menu.lst pour ne pas être obligé de réitérer la manip à chaque lancement.

RTL8111b sur P5B-VM sous Opensuse 10.1

Je viens d’acheter un carte mère Asus P5B-VM basée sur un chip réseau gigabit Realtek RTL8111b de la famille des r1000. Ce dernier n’est pas reconnu et mon installation réseau en est un peu compliquée … Je vous livre ici comment je m’en suis sorti …

Il est tout a fait possible de charger un module lors de l’installation, le tout etant de l’avoir. Pour cela, il faut recopiler le driver Realteck sur une suse de même version pour obtenir le module … je vous livre ici mon module pour la suse 10.1 (version 32b) et ici la version SMP pour suse 10.1… ca vous fera toujours gagner une etape ..

Pour ceux qui souhaitent le recompiler par eux-même, il y a deux choses à savoir :

  • Il faut modifier src/Makefile et remplacer $(PWD)/Makefile_linux26x par le chemin complet de ce même fichier
  • Il faut remplacer dans src/r1000_n.c les 3 lignes MODULE_PARM par MODULE_PARM_DESC

Ensuite il faut copier ce module sur une clef USB par exemple. Lancer l’installation et lorsque l’on arrive sur les premières fenetre de YAST
De là il faut :

  • Appuyer sur CTRL+ALT+F9 pour passer sur une console
  • Monter la clef usb : mount -t vfat /dev/sda1 /mnt
  • Ajouter le module : insmod /mnt/r1000.ko

En appuyant sur CTRL+ALT+F1, vous retournez alors sur l’installeur yast et l’installation réseau pourra commencer.

Attention, il faut aussi noter que le chipset G965 n’est pas reconnu avant le 2.6.18 et donc pas avant la suse 10.2. Toutefois ce n’est pas ce chip qui pose des problème mais le Southbridge JMicron qui n’etant pas du tout reconnu empèche la détection des disques dur IDE et même du CDROM une fois l’installation lancée. Cependant pour installer linux sur une SATA via le réseau, ca fonctionne …

Revenons à nos moutons … une fois Linux installé, il faudra se recompiler une nouvelle fois un driver, il ne faut donc surtout pas oublier d’installer le package kernel-source sans quoi, après c’est trop tard ! Au premier redemarage, dès que yast se lance, il est possible de trouver un console pour compiler un nouveau module. Attention, le Makefile ne fait pas de depmod -a lors de l’installation … pensez à l’ajouter !
Enfin, la recompilation sera à faire après les mise à jour de noyau … Au passage, pour forcer l’usage d’un module pour un périphérique reseau, il faut jeter un oeil dans /etc/sysconfig/hardware, c’est à cet endroi que l’association se fait.

Utilisation du Pata JMicron sur P5B-VM sous Opensuse 10.1

Bon … pour accéder au controleur PATA JMicron de la carte mère Asus … c’est pas gagné !!! En tout cas on finit par y arriver avec un peu de patience. Dans la doc c’est possible, et ca l’est en effet, mais ce n’est pas trivial. Je vous donne la liste des manip que j’ai dû faire :(sans pour autant garantir que tout soit utile

  • Dans le bios, configurer le JMicron en mode AHCI
  • Booter l’install de la 10.2 puis dès que possible passer sur un terminal (CTRL+ALT+F9)
  • Charger le module par modprobe pata_jmicron
  • Jeter un oeil avec dmesg pour voir ce qui s’est passé …

Pour ma part le cdrom est sur /dev/sr0 et le disque dur semble etre sur /dev/sdb

Cette manip faite il ets presque possible d’installer suse 10.2 à partir du CD, j’ai toutefois du passer par la case “vérification du support” avant que l’installeur veuille bien me monter le cdrom

Revenir au double click sous KDE

Franchement …. le simple clic c’est chiant !! passer son temps à ouvrir des documents alors qu’on souhaite faire une selection multiple est gavant ! bref, retour aux concepts initiaux : le double clic… problème où est cette foutue option dans KDE !

Après quelques longues recherches : la solution est

  • Panneau de config de KDE
  • Périphérique / Souris
  • Option Simple/Doucle clic

Sauvé !

Propagation de virus au travers de Wifi (anticipation)

Le fait de voir toutes ses AP visibles depuis mon réseau Wifi me font imaginer une nouvelle façon de propager un virus … un système nouveau efficasse et totalement automatique … Bien sure c’est totalement imaginaire, mais peut etre l’avenir ?
Voici quelques idées un peu en vrac…
Les virus que je trouve les plus impressionnant et interressant (disons intellectuellement parlant uniquement) sont ceux qui sont capable de s’auto-répliquer sans action de la part de l’utilisateur : ils sont emis par des machines infectées qui vous attaquent presque au hazard quand vous vous connectez sur Internet par exemple, s’installent puis se répliquent …

Le voie de contamination par l’Internet est connue, est en partie protégée par les systèmes de NAT et firewall intégrées aux routeurs.
Il existe maintenant une nouvelle voie de propagation : nos point d’accès Wifi. En effet, un virus, une fois installé sur une machine pourrait etre capable de scanner l’entourage wifi de votre réseau puis de mettre en oeuvre les technique d’attaque connue pour pénétrer ces réseaux voisins. Il pourra ensuite s’y dubliquer et les copies attaqueront les reseaux voisins… et ainsi de suite.

Avec le maillage Wifi actuel fournit par nos provider hexagonaux, la propagation de la contamination, en ville pourrait etre rapide et très large.

Les applications sont très larges et depassent d’usage classique d’un virus en permettant aussi la creation d’un reseau urbain logique multi-point de sortie / anonymisation …

Tout celà est totalement imaginaire, à ne surtout pas mettre en oeuvre bien sure, mais je trouve l’idée assez interressante.

Pour exister il faut au moins :

  • Une faille exploitable permettant l’auto-réplication des virus
  • Une methode d’attaque Wifi simple et rapide pour le Wep (on l’a) et le WPA
  • Une compatibilité de cette attaque avec le matériel wifi répendu et fonctionnant sous Windows

Avantages :

  • la diffusion du virus est quasiement impossible à tracer
  • La diffusion du virus passera par la voie des airs grace aux machines mobiles, elle penetre de fait une bonne parties de protections de réseaux classique
  • Elle peut s’en prendre à des appareils mobiles pourquoi pas (téléphones, PDA)

Applications :

  • Espionnage et surveillance
  • Constitution d’un reseau anonyme et utilisable de n’importe où en milieu urbain
  • Constitution d’un reseau à très fort maillage et donc très resistant
  • Classique groupe de robots d’attaque…

Cryptage WEP – Comment fonctionne-t-il ?

Quelques lignes pour décrire le fonctionnement d’un cryptage de type wep …
Le WEP (Wired Equivalent Privacy (lol)) repose sur un cryptage simple de type XOR (ou exclusif) entre la chaîne initiale et une clef de même longueur. La dite clef est obtenue par un algorithme RC4 initialisé à partir d’une clef partagée et un IV (Initialization Vector) aléatoire ou tout au moins dynamique.

Le cryptage se fait de la façons suivante :
– L’emetteur choisit un IV de 24 bits qu’il concatène à la clef partagée. De cette façon nous obtenons 2^24 clefs différentes à partir d’une clef partagée statique, elle même de 104 bits (pour un total de 128 bits).
– Le RC4 est initialisé avec cette clef : le but du RC4 est de remplir un tableau de 256 octets avec cette clef, puis de piocher dans ce tableau des valeurs tout en les modifiant au fur et à mesure. Cette methode permet à partir d’un clef d’obtenir une suite unique et pseudo aléatoire de valeurs à sa sortie.
– La sortie du RC4 est ensuite utilisée pour crypter la chaîne à envoyer. Le RC4 genère un flow de bits (ou octets) infini, il est donc tout à fait adapté au cryptage de données de longueur variable comme des trames réseaux.
– La trame est émise vers le destinataire en incluant l’IV de sorte que le destinaitre soit capable de recréer la même suite RC4 pour décrypter le message.
– Le recepteur est donc à même de générer une clef de (dé)cryptage identique à l’emeteur, issue de RC4, il ne lui reste plus qu’à appliquer la même fonction que pour le cryptage puisque (N XOR K) XOR K = N avec N le message initial.

Voila comment celà se passe, comment celà est-il attaqué alors ?
– Tout d’abord, avec une seule clef partagée, il y a 16M de clefs générées, ce qui signifie que la véritable clef de cryptage issue du RC4 change régulièrement, pour ainsi dire à chaque trame ce qui complique la donne.
– Pour attaquer ce type de cryptage, il faut donc tout d’abord s’attaquer à la véritable clef de crytage issue de RC4 et l’identifier ; en identifier un maximum. Pour se faire il est nécessaire de connaitre des données claires et cryptées, récupérer la clef est alors simple, il suffit d’appliquer : (N XOR K) XOR N = K. Cette opération est possible sur certaines trames récurentes dont l’entete est connue des ARP par exemple, ce qui permet de connaitre les premiers octets de la suite.
– Une fois que l’on a collecté de multiples entêtes de clefs issues de RC4 avec leur partie IV associée, il reste à trouver quelles sont les clefs sources ayant le plus probablement conduit à cette génération et ainsi déterminer la clef partagée initiale.
– Cette approche est statistique puisque plusieurs clefs peuvent conduire au même début de suite issu de RC4 (et nous ne connaissons que le début !) Ainsi nous ne pouvons calculer que des suppositions sur le contenu initial du tableau RC4 et eliminer des solutions impossibles.
– De fait pour optimiser la recherche, il est nécessaire, soit d’avoir un maximum de trames et d’IV (de 500.000 à 3 M en général), soit d’avoir des suites plus longues issues du RC4.