Impossible de déployer l’application : erreur ssh: Could not resolve hostname

/0 Commentaires/dans /par

Je me suis retrouvé face à un problème qui m’a fait m’arracher les cheveux; après avoir modifié ma configuration réseau, impossible de déployer mon application. Capistrano me renvoyait l’erreur suivante :

ssh: Could not resolve hostname xxx: Temporary failure in name resolution

De plus la connexion à mon serveur en ssh était très aléatoire lorsque je me connectais avec le nom de domaine, alors qu’avec l’adresse IP, tout se passait correctement.

En fait, j’avais tout simplement oublié de modifier la passerelle par défaut donc le fichier /etc/network/interfaces. Il m’a suffi de changer la passerelle  comme vous le voyez ci-dessous :

iface eth0 inet static
   address 192.168.1.100
   network 192.168.1.0
   netmask 255.255.255.0
   gateway 192.168.1.15

Redémarrer ensuite le réseau :

sudo /etc/init.d/networking restart

Et voilà !

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