Reconstruire son RAID1 après un crash

/0 Commentaires/dans /par

Vous avez vu dans un article précédent comment désactiver un disque dur dans une grappe RAID1. Ayant reçu le disque dur de remplacement par échange standard (merci Western Digital !), j’ai donc pu reconstruire mon RAID1.

Pour ce faire, j’ai procédé comme suit. Tout d’abord, il faut bien sûr installer physiquement le nouveau disque dans votre serveur. Après avoir redémarré la machine, tapez la commande suivante dans le terminal :

sudo fdisk -l

Vérifiez que votre nouveau disque est bien listé ; un message vous indique que le disque ne comporte pas de partitions. Notez bien le nom de ce disque (sda, sdb, sdc, etc).

Pour notre exemple, nous poserons que le disque valide est sda et le disque fraichement ajouté sdb.

Nous allons maintenant copier la partition du disque restant dans la grappe RAID pour initialiser le nouveau disque.  la commande à taper est la suivante :

sudo sfdisk -d /dev/sda | sfdisk /dev/sdb

Une fois le disque partitionné, nous pouvons l’ajouter à notre grappe RAID en tapant la commande suivante (à adapter en fonction des partitions, des grappes que vous utilisez sur votre serveur).

sudo mdadm --manage /dev/md0 --add /dev/sdb1

Vérifiez l’état de votre grappe en tapant la commande suivante :

cat /proc/mdstat

Votre nouveau disque doit être listé, mais comme spare [S], puisque nous n’avons pas encore passé notre grappe à 2 disques.  Pour augmenter la taille de notre grappe, il faut taper la commande suivante :

sudo mdadm --grow --raid-devices=2 /dev/md0

Cette commande va également lancer la reconstruction de la grappe ; vous pouvez en suivre la progression en tapant :

cat /proc/mdstat

Nous n’en avons pas tout à fait fini ; il faut maintenant modifier le fichier mdadm.conf pour y inscrire notre nouvelle taille de grappe :

ARRAY /dev/md/0 level=raid1 num-devices=2 metadata=1.2 UUID=02dd0a9a:d714cba8:83f756df:a95a8b51 name=test:0

Enfin, nous allons ajouter grub à notre nouveau disque, pour que le serveur puisse redémarrer en cas de problème sur l’autre disque :

sudo dpkg-reconfigure grub-pc

En choisissant les disques sda et sdb (et pas md0).

Enfin, pour s’assurer que le système redémarrera bien automatiquement même si un des disques tombe, il faut modifier un paramètre du fichier /etc/initramfs-tools/conf.d/mdadm :

BOOT_DEGRADED=true

Redémarrez votre serveur pour vérifier que tout fonctionne bien.

Via howtoforge.com, kernel.org

Déplacer une application Rails d’un serveur à un autre

/0 Commentaires/dans , /par

Ayant recyclé une machine plus puissante comme serveur interne, je me suis trouvé face à la tâche fastidieuse de déplacer mes applications Rails d’un serveur à l’autre. Je détaille ici à titre d’aide-mémoire les opérations à effectuer, les problèmes rencontrés et les solutions apportées.

Recopier les fichiers de l’application

Pour recopier les fichiers de l’application, deux possibilités : modifier votre fichier de déploiement si vous utilisez capistrano, c’est la méthode la plus pérenne; en mode « quick and dirty », je passe par rsync pour synchroniser les répertoires.

Pour cette deuxième méthode, connectez vous à votre serveur source, et tapez la commande suivante :

rsync -a /source/path/to/myapp/ user@mytargetserver.org:/target/path/to/myapp/

Vous devrez bien sûr donner le mot de passe de user sur mytargetserver.org.

Migrer la base de données

Nous allons tout d’abord exporter les données depuis le serveur mysql source. Connectez-vous à votre serveur source en ssh et exportez la base de données avec la commande suivante :

mysqldump -u user -pmypassword myapp_production > myapp_production.sql

Recopiez la base de données sur votre machine cible, en utilisant par exemple la commande scp :

scp myapp_production.sql user@mytargetserver.com:

Connectez-vous à votre machine cible, lancez mysql et tapez la commande suivante pour créer votre base de données :

create database redmine_production;

Donnez les droits à votre utilisateur mysql sur votre base de données ; pour ce faire, lancez mysql avec votre utilisateur root et votre mot de passe, puis tapez la commande suivante :

grant all on myapp_production.* to 'myrailsuser'@'localhost';

Quittez mysql et importez ensuite votre base de données en tapant la commande   suivante :

mysql -u user -pmypassword myapp_production < my app_production.sql

Problèmes rencontrés

Fatal error lors du bundle install

Mon application n’était plus installée au même endroit que précédemment, et bundler avait gardé en configuration le chemin ou se trouvait le bundle sur la précédente machine. J’ai eu droit à un joli message du genre :

Unfortunately, a fatal error has occurred. Please see the Bundler troubleshooting documentation at http://bit.ly/bundler-issues. Thanks!

Avec comme information supplémentaire qu’il n’arrivait pas à créer une arborescence de répertoires dans /var/www

Pour trouver l’endroit du stockage, il suffit de taper :

bundle config path

Editez le fichier qui contient la configuration locale avec votre éditeur préféré et faites le pointer sur le répertoire bundle de votre application.

Impossible de trouver un gem lors de bundle install

Si lors de l’installation des gems avec bundle vous obtenez la sortie suivante :

Fetching gem metadata from http://rubygems.org/..
Could not find gem-xxx in any of the sources

Ou gem-xxx peut être n’importe lequel de vos gens, il vous suffit de procéder comme suit :

  1. Supprimer le fichier Gemfile.lock
  2. Modifier le fichier de configuration locale de bundler (chemin visible avec bundle config) pour passer le paramètre freeze à 0 au lieu de 1.
  3. Relancer la commande bundle install
  4. Modifier le fichier de configuration de bundler pour remettre freeze à 1.

RAID1 en vrac et grub rescue

/0 Commentaires/dans /par

Pour sécuriser mes données personnelles, j'avais décidé de monter un système en RAID1, basé sur le gestionnaire logiciel fourni avec Ubuntu, mdadm. Manque de chance, l'un des disques tout neuf achetés pour l'occasion a claqué quelques semaines après son achat, et au démarrage, le système m'envoyait vers grub rescue, avec comme message : out of disk.

Je pensais naïvement que l'intérêt d'un RAID était justement de démarrer même si l'un des disques était défaillant, mais là ça ne marchait pas. En bootant sur un autre disque, je pouvais voir mes deux disques RAID, et constater en tapant la commande cat /proc/mdstat qu'un des disques n'était plus reconnu.

Après m'être arraché les cheveux, je suis tombé sur un article qui préconisait de réduire le RAID à un seul disque. On commence d'abord par marquer le disque comme défaillant, puis le supprimer du RAID :

sudo mdadm --manage /dev/md0 --fail /dev/sdb1

sudo mdadm --manage /dev/md0 --remove /dev/sdb1

Ensuite, nous pouvons indiquer à notre RAID que nous ne voulons plus utiliser qu'un seul disque :

sudo mdadm -G /dev/md0 -n 1 --force

Après redémarrage (en débranchant le disque fautif), le serveur remonte correctement. Prochaine étape, renvoi du disque défaillant à WD, réinstallation du nouveau disque et resynchronisation.

Via askubuntu.com

 

Associer branche et base de données

/0 Commentaires/dans /par

Si vous utilisez git pour développer vos applications rails, vous êtes certainement un adepte des branches, qui vous permettent de développer vos nouvelles fonctionnalités en gardant au chaud votre branche « master », qui doit correspondre à tout moment à votre application en production.

Git, branches et base de données

Git, branches et base de données

Tant que vos modifications ne concernent que votre source, pas de problème ; mas si vous touchez à la base de données, vous courez à la catastrophe, puisque cette dernière est partagée entre toutes vos branches.

Heureusement, Mislav Marohnić a développé un petit hack du fichier database.yml qui permet de lever ce problème d’une manière élégante :

  • Récupérer le nom de la branche courante
  • Vérifier que vous souhaitez bien utiliser une base de données alternative grâce à un flag posé dans la configuration de git
  • Suffixer le nom de votre base de données avec le nom de la branche

Cela se traduit de la manière suivante :

## database.yml (after) <% # http://mislav.uniqpath.com/rails/branching-the-database-along-with-your-code/ 
branch = `git symbolic-ref HEAD 2>/dev/null`.chomp.sub('refs/heads/', '') 
suffix = `git config --bool branch.#{branch}.database`.chomp == 'true' ? "_#{branch}" : "" %> 

development: 
# ... autres infos de configuration de la base de données ... 
database: myapp<%= suffix %>

Il faudra également positionner le flag dans la configuration de git :

$ git config --bool branch.feature.database true

Créez ensuite la nouvelle base de données et appliquez le schéma de celle-ci avec les commandes de Rails suivantes :

rake db:create
rake:db:schema:load

Et voià le travail !

via mislav.uniqpath.com

Redémarrer le serveur munin après l’ajout d’un noeud

/0 Commentaires/dans /par

Pour redémarrer munin après l’ajout d’un nouveau noeud à votre fichier de configuration /etc/munin/munin.conf, il faut exécuter une commande sous l’identité de l’utilisateur munin qui a été ajouté lors de l’installation du package. Il vous faut taper les commandes suivantes :

sudo su
su - munin --shell=/bin/bash
/usr/share/munin/munin-update
exit

Vous devriez normalement voir arriver les nouvelles données des noeuds ajoutés à votre configuration.

Via munin-monitoring.org