Tar vers autre serveur

tar zcvf - . | ssh -l username hostname "cat > /path/backup.tgz"

Flush memcached

Flush le cache de Memcached

Facile, c'est partout sur google mais je le remets pour moi parce que j'oublie :

echo 'flush_all' | nc localhost 11211

A utiliser avec Zabbix, Fabric ou n'importe quoi pour l'automatiser.

Au secours, impossible de vzdump

Impossible de realiser des backups, vzdump affice l'erreur suivante :
unable to parse worker upid 'UPID:ds0371:00023136:1001D7AE5:5201EC1A:vzdump::root@pam:'

Evidement une mise a jour corrige probablement le probleme mais je ne peux pas redemarrer.

Heursement j'ai trouve la reponse sur le forum Promox :

http://forum.proxmox.com/threads/15341-Can-t-perform-backup

Comme indique j'ai mis a jour les fichiers :
/usr/share/perl5/PVE/Tools.pm
/usr/share/pve-manager/ext4/pvemanagerlib.js

Redemarrer les services pvedaemon et apache2.
/etc/init.d/pvedaemon restart
/etc/init.d/apache2 restart

Et maintenant le backup affiche quelques heures au moment de l'execution mais fonctionne.
Reste a planifier un upgrade et reboot de proxmox.

Lecture de Mastering Zabbix

Cette semaine j'ai lu Mastering Zabbix publie chez Packt Publishing.
Une lecture intéressante qui décrit la mise en œuvre de Zabbix dans un environnement de production exigeant et en fait un outil majeur de son infrastructure.

Mastering Zabbix from Packt Publishing, by Andrea Dalle Vacche

http://www.packtpub.com/monitor-large-information-technology-environment-by-using-zabbix/book

A ma connaissance c'est le second livre traitant de Zabbix. Le premier datait de la version 1.8 depuis Zabbix a beaucoup évolué et il était nécessaire de mettre a jour la littérature Zabbixienne.

Mastering Zabbix séduit en premier par sa mise en œuvre réaliste, décrivant un environnement de production réaliste et complexe. Pour cette raison la solution décrite prévoit une architecture distribuée et redondante qui permettra de mettre en œuvre une solution stable, pérenne mais qui permettra également de réaliser les taches de maintenance nécessaire (Backup, upgrade, …) sans sacrifier la sécurité et la qualite de service.

Ainsi la solution Zabbix décrite par l'auteur permet de réaliser une solution de supervision mais également de capactiy planning qui aidera pleinement le service IT.

Car en effet bien mis en œuvre Zabbix devient une véritable solution chargée de la supervision et également, d'alerter, d'intervenir, de prévoir et de reporter.

Dans cette optique Mastering Zabbix aborde de façon intéressante :

• l'infrastructure détaillée a mettre en oeuvre.
• l'utilisation de proxy ou de node dans le cas d'une architecture distribuée. 
• détaille l'utilisation de zabbix sender et zabbix trapper. 
• le fonctionnement des agents passif et actif. 
• la supervision Java a l'aide de JMX. 
• l'aspect supervision et capacity planning. 
• comment étendre l'utilisation de Zabbix grâce son Api. 
• un exemple d'interaction avec RT Tracker. 
• les options pour visualiser les données. 

En somme Mastering Zabbix décrit une mise en pratique complète de Zabbix qui permettra a tous une prise en main efficace ou aidera a solutionner les problèmes d'une solution existante mais malheureusement l'auteur ne couvre pas les dernières innovations comme Low Level Discovery ou l'utilisation et l'optimisation de Mysql.

Ce livre est donc une bonne introduction et théorisation mais manque de mettre en valeur la dernières nouveautés de Zabbix.

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