werk.feub.net

Depuis hier edoras ma vieille config qui me sert de serveur fourre-tout sous Fedora 11 ne démarrait plus. J’avais depuis un certains temps un disque qui jouait du grattoir à faire un bruit pas possible qui normalement devrait alerter n’importe qui qu’il faut s’en occuper. Mais bon, j’ai laissé courir en me disant que ça allait bien tenir et que je regarderais plus tard. J’ai attendu trop longtemps.

Je passe sur les détails du comment du pourquoi je m’en suis dépatouillé pour récupérer mes données (229Go de photos et de musique) sur du LVM réparti sur 2 disques avec un disque marqué inexistant. Mais j’ai réussi.
Edoras est d’une part un vieux coucou (Sempron 2400+ avec 1Go de RAM), mais très bien pour un petit serveur qui démarre en niveau 3. Mais c’est aussi une usine à gaz qui comporte 5 disques : un disque système avec 2 partitions /boot et l’autre en LVM (swap, root et home), un VGdata de 380Go sur 2 disques et un VGraid qui comme son l’indique est un RAID1 sur deux disques SATA de 500Go. Non seulement, j’ai eu ce problème d’inconsistance du VGdata, mais j’avais un des disques du RAID déconnecté. Et ne me demandez pas pourquoi, ce deuxième disque avec un identifiant de partition de type Linux LVM (8e) et non pas Linux RAID auto (fd). Je l’ai donc ré-attribué l’id du système de fichiers comme étant fd. Et j’ai du ré-ajouter le disque au RAID pour le resynchroniser.

Ajout du disque à la pile raid md127 :

# mdadm --add /dev/md127 /dev/sde1
mdadm: added /dev/sde1

Voilà, la synchronisation doit commencer toute seule :

[edoras@edoras ~]# cat /proc/mdstat 
Personalities : [raid1] 
md127 : active raid1 sde1[2] sdd1[0]
      488383936 blocks [2/1] [U_]
      [>....................]  recovery =  2.7% (13261248/488383936) finish=137.9min speed=57399K/sec
 
unused devices: <none>

Plus qu’une bonne 130aine de minutes à attendre pour avoir ses données sécurisées de nouveau.

Petite anecdote pour commencer ce billet, il m’aura fallu toutes ces années pour me rendre compte que le nom de mon petit serveur domestique edoras est à une lettre près (bon allez deux, mais l’autre est plutôt muette) Fedora. Youpie!

Leonidas est dans la place

Après une tentative plutôt infructueuse par le biais de preupgrade – tout se passait bien, mais après la demande de redémarrage, j’étais toujours sous F10 – j’ai décidé de télécharger le DVD de Leonidas, ne serait-ce que pour l’avoir, et de faire la mise-à-jour.

Celle-ci s’est bien passée, mais les problèmes ont débuté avec YUM qui n’était plus là : no module named yum et un soucis de version du paquet rpm-python. J’ai vite vu que c’était toujours la version F10 du gestionnaire de paquets qui était présente, d’où le problème de dépendance relatif à python. J’ai donc installé le RPM de YUM pour F11 et tout est rentré dans l’ordre. J’ai pu mettre à jour cette F11 (pas vraiment) fraîchement installée.

Le gros du soucis a été du côté du serveur DHCP, celui-ci ne voulant absolument pas démarrer. Les logs m’indiquaient qu’il fallait spécifier l’interface réseau utilisée dans le dhcpd.conf comme j’ai deux cartes réseaux. J’ai retourné la doc d’ISC et les forums pendant une bonne heure et demi (je n’ose pas dire deux..) pour m’apercevoir que désormais le fichier de configuration se trouve sous /etc/dhcp et non plus directement sous /etc. L’adage « Petite cause, grands effets » est souvent de mise en informatique – genre pour les problèmes en séries – mais là c’était « Grand effet, petite cause« .

OS 3.0 pour iPhone

Le passage a F11 m’a permis la mise-à-jour de l’iPhone également. Petite étape en OS officiel avant le jailbreak dès qu’il sera disponible.
D’apparence aucun lien entre les deux sujets de ce billet si ce n’est que j’avais besoin d’edoras pour cette opération car ma bibliothèque iTunes est sur un volume NFS du serveur linux, donc pas d’iTunes, pas de mise-à-jour de l’iPhone.

Au menu des nouveautés en vrac donc : enfin le copier-coller-couper, dictaphone, MMS, mode paysage généralisé, Spotlight, synchro des notes, secouer l’appareil pour mélanger….

Cette opération est lourde et longue, mais j’ai décidé de modifier le partitionnement de mon petit serveur edoras actuellement sous Fedora 10.
En effet, depuis de nombreuses années, j’utilisais un partitionnement classique, et depuis Cambridge, je suis passé à LVM (enfin!) et même au RAID 1 pour encore plus sécuriser mes sauvegardes photos. Le RAID a été ajouté avec deux disques non utilisés, mais il me restait deux autres disques avec une seule partition chacun sdb1 et sdc1 bourrés de données et montés de façon classique, respectivement en /data1 (200Go) et /backup (160Go), ces deux partitions étant utilisés en montages NFS sur mon réseau (et TRES solicités).

Avant :

$ df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/VG1-LVroot
9,9G  3,7G  5,7G  40% /
/dev/mapper/VG1-LVhome
26G  853M   23G   4% /home
/dev/sdc1             145G   83G   54G  61% /backup
/dev/sdb1             184G  111G   64G  64% /data1
/dev/sda1             236M   29M  195M  13% /boot
/dev/mapper/VGraid-LVraid
459G  216G  220G  50% /raid

D’une part, cela me faisait beaucoup de montages (NFS) sur mes Mac alors que je pouvais – théoriquement – rassembler /backup et /data1 en un seul volume, et d’autre part, je désirais passer en full LVM pour plus de flexibilité.

La limitation des systèmes de fichiers classiques m’imposait d’avoir ces deux partitions séparées, celles-ci étant sur deux disques différents. C’est là que LVM montre sa puissance : la possibilité de créer un groupe de volumes sur les deux disques, soit au final avoir une seule partition virtuelle de 360Go unique sur les deux disques.

Après :

$ df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/VG1-LVroot
9,9G  3,7G  5,7G  40% /
/dev/mapper/VG1-LVhome
26G  855M   23G   4% /home
/dev/mapper/VGdata-LVdata
331G  1,8G  312G   1% /mnt/data
/dev/sda1             236M   29M  195M  13% /boot
/dev/mapper/VGraid-LVraid
459G  275G  162G  63% /mnt/raid

Après avoir déplacé mes données sur un autre disque pour faire la modification, redéfini sdb1 et sdc1 en partition de type 8e (Linux LVM) dans fdisk, j’ai opéré comme suit pour ajouter un groupe de volumes VGdata contenant un unique volume logique LVdata de la totalité de l’espace disponible (je ne détaillerai pas, les étapes ayant été un peu mieux expliquées dans ce billet) :

# pvcreate /dev/sdb1
# pvcreate /dev/sdc1
# vgcreate -s 16M VGdata /dev/sdb1 /dev/sdc1
# lvcreate -l 21462 VGdata -n LVdata
# mkfs.ext3 /dev/VGdata/LVdata
# mkdir /mnt/data
# mount /dev/VGdata/LVdata /mnt/data

Ajout du montage dans fstab :

/dev/VGdata/LVdata	/mnt/data		ext3	defaults	1 2

Que de déménagements ces deux dernières semaines, que de déceptions aussi. Je pense que le(s) site(s) est désormais disponible et va le rester. Je suis de retour sur un serveur Haisoft, presque à la maison comme avant.

Media Temple puis Lycos

J’avais décidé de migrer le site chez un autre prestataire pour changer un peu comme on dit, et parce que je trouvais que l’accès au site chez Haisoft était de plus en plus difficile. Mais qu’elle ne fut ma surprise lorsque tout content d’être sur un Grid Server de chez Media Temple, je me retrouve avec un site d’une lenteur extrême, aussi bien en HTTP qu’en FTP, que sur leur interface d’administration (sublime d’ailleur).
Leurs offres souples me permettent de payer mensuellement et de résilier à tout moment, pas de période minimale d’engagement. Après une petite quinzaine, je franchis le pas, résilie et sans trop réfléchir, je commande un hébergement chez Lycos Webcenter un pack Tout compris + malgré quelques avis assez négatifs piochés à droite et à gauche sur la toile.
Qu’elle ne fut mon erreur! Wouaw. Le pire étant qu’en 2 jours, je n’ai pas pu accèder à PHPMyAdmin. No comment. J’ai fait jouer mon droit de rétractation de 7 jours (le gentil opérateur me précisant que c’est porté à 30 jours chez Lycos) et demande la résiliation malgré l’engagement d’un an que je n’avais pas vu au départ. Terminé Lycos.
Me revoilà donc chez Haisoft qui finalement est très bien à beaucoup de niveaux, en particulier un service de support très éfficace, rapide et compétent. Pourquoi diable j’avais voulu changer?

Re-centrage

J’en ai également profité pour faire un re-centrage du design de feub.net, la dominante verte laissant la place à un rouge prononcé.
A noter que le blog est désormais disponible via http://werk.feub.net et non http://www.feub.net/werk comme avant.