Restore LVM metadata

Je partage ma récente aventure, après le reboot d'un serveur NFS qui exporte plus de 10Tb en 69 Filesystem.
Au redémarrage, seuls 60 FS sont présents, neufs sont absents.
Par exemple :
PV unknown device               VG vgFS58        lvm2 [50.00 GB / 0    free]
mount: special device /dev/mapper/vgFS58-lvfs58 does not exist

Passé les doutes, l'analyse du multipath montre que les FS sont bien présenté au serveur par le NAS mais que les VG sont indiqué comme partial.

vgFS58        8   1   0 wz-pn- 409.97G      0 

Il ne s'agit pas de d'activer le VG ou le LV avec vgchange -ay ou lvchange -ay mais de restorer la métadata qui a disparu.

A la recherche des devices perdus

Commence alors la recherche des devices perdus, pour le FS58 il s'agit de 4 devices.
  unknown device             vgFS58      lvm2 a-    50.00G      0 
  unknown device             vgFS58      lvm2 a-    50.00G      0 
  unknown device             vgFS58      lvm2 a-    50.00G      0 
  unknown device             vgFS58      lvm2 a-    50.00G      0

Il fautt retrouver le device et réapliquer la metadata manquante.
Multipath indique les devices :

# multipath -l | grep fs58
lvm6fs58 (36005076305ffc0290000000000002539) dm-286 xx,xx
lvm1fs58 (36005076305ffc0290000000000002535) dm-269 xx,xx
lvm7fs58 (36005076308ffc536000000000000066b) dm-187 xx,xx

Pour vérifier l'état d'un device :
# pvck /dev/dm-269
Could not find LVM label on /dev/dm-269

On est donc sur que le device ne contient pas de metadata, il faut donc la restaurer.
Je sais qu'il s'agit du premier device, pour rechercher dans son id, l'info dans /etc/lvm/archive/vgFS58_00009.vg 

Il reste à l'appliquer :
# pvcreate --uuid "p5bjql-fCXc-vTCe-KBuF-2DgF-X2rl-UfZCti" --restorefile /etc/lvm/archive/vgFS58_00009.vg /dev/dm-269

Bingo !

Une fois toutes les métadatas restaurés, le VG redevient disponible :
# vgs vgFS58
  VG     #PV #LV #SN Attr   VSize   VFree
  vgFS58   8   1   0 wz--n- 409.97G    0 

On réactive le LV
# lvchange -ay vgFS58/lvfs58

Reste à scan le FS
# e2fsck /dev/mapper/vgFS58-lvfs58
e2fsck 1.41.9 (22-Aug-2009)
e2fsck: Group descriptors look bad... trying backup blocks...
/dev/mapper/vgFS58-lvfs58: recovering journal
e2fsck: unable to set superblock flags on /dev/mapper/vgFS58-lvfs58

# e2fsck /dev/mapper/vgFS58-lvfs58  -y
e2fsck 1.41.9 (22-Aug-2009)
One or more block group descriptor checksums are invalid.  Fix? yes

Et le tour est joué, on peut mount avec succès le FS.

Restait plus que 8 autres FS et environ 20 devices.
Mais tout c'est bien déroulé, il a été possible de récupérer l'accès aux données.

En résumé :

• Rechercher des informations : 

# multipath -l | grep fs58
# grep -i id /etc/lvm/archive/vgFS58_00009.vg
# pvck /dev/dm-269

• Restauration metadata

# pvcreate --uuid "p5bjql-fCXc-vTCe-KBuF-2DgF-X2rl-UfZCti" --restorefile /etc/lvm/archive/vgFS58_00009.vg /dev/dm-269

• Contrôle

# vgs vgFS58

• Activacion LV

# lvchange -ay vgFS58/lvfs58

• Vérification du FS

# e2fsck /dev/mapper/vgFS58-lvfs58  -y

• Disponibilité du FS

#mount /dev/mapper/vgFS58-lvfs58 /FS58

Fabric, la toolbox des champions

Fabric, mon rêve d'automatisation.

Mon aventure avec Fabric ne fait que débuter et commence sur 2 constats et problématiques :

• La lecture des posts suivants : vos 5ères minutes sur un serveur (blog.nicolargo.com, plusbryan.com)
• La répétition des commandes et l'application de changement à grande échelle.

C'est vrai, je fais quoi durant mes 5ères minutes, je me souviens pas toujours.

Et puis j'en ai marre de répéter toujours les mêmes commandes.

J'aurais pu faire des scripts en bash, je les ai déjà mais bof.

Je ne veux pas installer un serveur d'application et déployer des clients pour automatiser.

Je ne veux pas faire du ruby.

Je ne veux une solution agile.

Je veux pouvoir le transmettre à mes collègues sans les forcer.

Je veux faire du python.

Donc pas de Puppet, ni Chef même si ça a l'air très bien.

Heureusement je découvre Fabric.

Notamment ses infos :

• Sildes
• Fabric + Cuisine (forcement ça attire mon intérêt)
• Un article complet

Je décide de regrouper mes 2 problématiques standardisation et automatisation.

Setup serveur initial

Mes 5 min sur un serveur :

1. installer fail2ban
2. installer cron-apt
3. installer logwatch
4. Mettre a jour l'environnement (PS1, .vimrc, .bashrc)
5. installer shorewall (sans le configurer)

Fabric

Traduit en Fabric ca donne :


from fabric.api import *
from cuisine import *
from fabric.colors import cyan,magenta,red
from fabric.contrib.files import comment, uncomment, contains, exists, append, sed

@task
def PS1_host():

   append('/root/.bashrc','export PS1=\'\[\033[01;31m\]\u\[\033[01;33m\]@\[\033[01;36m\]\h \[\033[01;33m\]\w \[\033[01;35m\]\$ \[\033[00m\]\'',use_sudo=False)

@task
def update_upgrade():
    run('aptitude update && aptitude full-upgrade')

@task
def vim_color():
    append('/root/.vimrc','syntax on')

@task
def cront_apt_setup():
    if not package_ensure_apt('cron-apt','update=False')
    append('/etc/cron-apt/config','APTCOMMAND=/usr/bin/aptitude')
    append('/etc/cron-apt/config','ACTIONDIR="/etc/cron-apt/action.d"')
    append('/etc/cron-apt/config','MAILTO="moi@gmail.com"')
    append('/etc/cron-apt/config','ERROR="/var/log/cron-apt/error"')
    append('/etc/cron-apt/config','LOG="/var/log/cron-apt/log"')
    append('/etc/cron-apt/config','LOG="/var/log/cron-apt/log"')
    append('/etc/cron-apt/config','MAILON="always"')
    append('/etc/cron-apt/config','SYSLOGON="upgrade"')
    append('/etc/cron-apt/config','OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/sources.list"')
    file_append('/etc/cron-apt/action.d/5-install','autoclean -y\n safe-upgrade -y -o APT::Get::Show-Upgraded=true')

@task
def logwatch():
    if not package_ensure_apt('logwatch','update=False'):
   run('aptitudsilverstone install -y logwatch')
   run('cp -a /usr/share/logwatch/default.conf/* /etc/logwatch/conf/')
   run('cp -a /usr/share/logwatch/scripts/* /etc/logwatch/scripts/')
   run('mkdir -p /var/cache/logwatch')
   sed('/etc/logwatch/conf/logwatch.conf',before='MailTo = root',after='MailTo = moi@gmail.com')
   sed('/etc/logwatch/conf/logwatch.conf',before='Detail = Low',after='Detail = Med')
   run('logwatch')

@task

def shorewall_install():

    if not package_ensure_apt('shorewall','update=False')

    print(red("Don't forget to configure SHOREWALL"))

@task
def install_fail2ban():
if not package_ensute_apt('fail2ban','update=False')
sed('/etc/fail2ban/jail.conf',before='destemail = root@localdomain',after='destemail=moi@gmail.com')
run('service fail2ban restart')

Bien sur ce post reflète mon expérience actuelle avec Fabric, je ne le maîtrise pas encore mais ça me permet déjà de faire des trucs très sympas, de standardiser et d'automatiser.

Par exemple, reste a créer une task install appelant les autres, de créer un organisation répertoire/fichiers, de piocher les hosts dans la base glpi et mettre tout ca dans un svn.

Fabric est très complet, permet déxecuter toutes les taches courantes, installer des paquets, gérer les utilisateurs/groupes, les services, ...
Le tout en python, Fabric peut donc être inclut dans d'autre projets.

Derniers petits trucs pour la route

Par défaut Fabric recherche son fabfile.py dans le répertoire courant ou bien s'il est spécifié à l'execution :

fab -f /home/someplace/fabfile.py

Mais Fabricpermet de créer un fichier .fabricrc qui spécifiant l'emplacement du fabfile.py, par exemple :

#cat .fabricrc 

fabfile=/home/FABRIC/fabfile.py

export $fabfile

De cette facon on peut executer directement fab -l pour voir la liste des commandes :

$ fab -l

Available commands:

    Instalacion_SVN_1_7_8  Instalacion de SVN CollabNet 1.7

Dernier truc qui m'a couté avant dý parvenir charger une list d'host a partir d'un fichier :

@task

def host_list():

        env.warns_only = 'True'

        with open('/home/julien/caf/caf/1-list.org') as fd:

         env.hosts = [x.strip() for x in fd]

De cette facon je peux combiner les commandes et installer logwatch sur tous les hosts défini dans ma liste.

fab host_list logwatch

Je peux également paralélliser l'installation par groupe de 5 :

fab host_list logwatch -P -z 5

Enfin, dernier conseil la documentation est très bien faite, très complète et facile a lire. La communauté est reactive par IRC ou mailing list.
L'essayer c'est l'adopter.

Au secours je peux plus entrer

En migrant de version de proxmox ou d'OpenVZ des CT Ubuntu.
Je me trouve enfermé dehors, pas ce vzctl enter, pas de ssh


root@x ~ # vzctl enter 600
enter into CT 600 failed
Unable to open pty: No such file or directory

Oups, beaucoup de recherche sur le internet mais beaucoup de solutions utilisant des CT Centos.
J'ai finalement trouvé une solution que me convient, les recréer dans /dev.

root@x ~ # vzctl exec 600 "cd /dev; /sbin/MAKEDEV pty"

root@x ~ # vzctl enter 600

Par contre je n'ai pas trouvé de solution permanente.

J'ai bien essayé les conseils désactivé udev, supprimer, etc ... sans succès.

En attendant je redémarre pas souvent et ça marche

Jouer avec les FS et les clusters

Je réinstalle un cluster, je souhaite monter mon FS ext4 qui était en cluster pour récupérer les données du backup.

Mais impossible :
Skipping Cluster Volume group

Remede, desactivé le lock lvm pour ce VG, puis l'activer, l'importer et le monter.
vgchange -cn vgname --config 'global {locking_type = 0}'
vgchange -ay vgname
vgimport vgname
lvchange -ay /dev/mapper/vgname-backup--gfs


Et maintenant comment faire pour monter directement dans mon nouveau cluster mon FS GFS2 ?
Erreur :
/sbin/mount.gfs: fs is for a different cluster 

/sbin/mount.gfs: error mounting lockproto lock_dlm

Facile, on récrit sur la metadata, la table du lock.

 gfs2_tool sb /dev/mapper/vgGFS-lvGFS table nouveacluster:nouveaupointdemontage

 mount /dev/mapper/vgGFS-lvGFS /u01/

Udev rules pour disk ASM

RHEL 6.3 n'étant pas certifié par Oracle, pas d'outils oracleasm pour créer des disk.
Obliger de passer par d'autres méthodes (multipath, mknod) ou bien des règles udev.

Je préfère les règles udev car elles permettent de préciser le repertoire souhaité, propiétaire et permissions et bien plus...

Le plus simple est de créer une nouvelle règle. Elles sont appliquées par ordre.
99.asm.rules sera donc appliqué en dernier. Important la nom doit terminer par ".rules"
On remplace le numéro de DM par * pour éviter les changement la filtre se base sur le numéro de série.

Pour trouver le numéro de série

Regarder /etc/multipath/wwids
ou bien : ls -al /dev/disk/by-id
ou encore : udevadm info --query=all --path=$(udevadm info -q path -n /dev/mapper/mpathc)

Exmple de contenu :
KERNEL=="dm-*",SUBSYSTEM=="block",ENV{DEVTYPE}=="disk",ENV{DM_UUID}=="mpath-2001738000f87036c",NAME+="oracleasm/disks/DSK1",OWNER="grid",GROUP="oinstall",MODE="0660"

KERNEL=="dm-*",SUBSYSTEM=="block",ENV{DEVTYPE}=="disk",ENV{DM_UUID}=="mpath-2001738000f87036d",NAME+="oracleasm/disks/DSK2",OWNER="grid",GROUP="oinstall", MODE="0660"

KERNEL=="dm-*",SUBSYSTEM=="block",ENV{DEVTYPE}=="disk",ENV{DM_UUID}=="mpath-2001738000f87036e",NAME+="oracleasm/disks/DSK3",OWNER="grid",GROUP="oinstall",MODE="0660"

KERNEL=="dm-*",SUBSYSTEM=="block",ENV{DEVTYPE}=="disk",ENV{DM_UUID}=="mpath-2001738000f87036f",NAME+="oracleasm/disks/DSK4",OWNER="grid",GROUP="oinstall",MODE="0660"

KERNEL=="dm-*",SUBSYSTEM=="block",ENV{DEVTYPE}=="disk",ENV{DM_UUID}=="mpath-2001738000f870370",NAME+="oracleasm/disks/DSK5",OWNER="grid",GROUP="oinstall",MODE="0660"

Pour appliquer la règle sans redémarrer :

udevadm trigger