Problèmes et Solutions
Gandi vous fournit un serveur virtuel adapté à vos besoins. Notez cependant que les nombreux avantages d'un tel serveur impliquent des responsabilités liées au bon fonctionnement du système. Gandi ne peut intervenir dans votre gestion du serveur, corriger des erreurs à votre place ou encore vous assister quant à sa configuration.
Si cela ne passe toujours pas, l'arrêt / démarrage en deux temps qui permet à l'instance d'être réinitialisée est une procédure qui peut faire passer certaines opérations.
Si l'opération n'aboutit toujours pas, vous pouvez contacter notre support par le formulaire !
Voici un tableau vous permettant de consulter les solutions aux problèmes les plus fréquemment rencontrés.
- Comment me connecter à mon serveur ?
Connectez vous par SSH à votre serveur
- Mon serveur ne répond pas !
Utilisez alors la console d'urgence du mode expert
- Comment installer des applications sur mon serveur ?
Sur Ubuntu ou Debian, utilisez Apt-get ou Aptitude - Sur CentOS ou Fedora, utilisez alors Yum au lieu d'Apt-get
- J'obtiens le message “E: Couldn't find package” lors de l'installation d'une application
- Je ne parviens pas à charger des fichiers sur mon serveur !
- J'ai le message WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! quand j'essaye de me connecter sur mon serveur
- si vous n'avez fait aucune modification sur votre serveur, ce message peux indiquer que votre serveur ait été compromis. Connectez-vous en utilisant la console d'urgence pour vérifier votre machine virtuelle. Une autre solution serait de stopper le serveur, d'attacher le disque système à un autre serveur pour vérifier si quelqu'un s'est introduit dans votre système.
- si vous avez supprimé récemment un serveur et créé un nouveau avec la meme adresse IP, vous pouvez supprimer la clé stockée localement sur votre machine avec la commande :
ssh-keygen -R votre_adresse_IP
- Je ne trouve pas le module “XXXX” dans le système d'exploitation de ma machine virtuelle.
Mettez alors à jour les modules de votre noyau (kernel)
- J'ai une erreur lors de la mise a jour des paquets .deb faits par Gandi
Corrigez les erreurs pour mettre à jour les paquets.
- J'ai agrandi le disque sur l'interface mais cela ne change pas sur le serveur lorsque je tape la commande 'df -h'
Il vous faut suivre la procédure d'agrandissement pour votre disque, attention, celle-ci diffère selon que le disque soit de type données ou système. Le paquet gandi-hosting-vm doit être à jour, si vous ne l'aviez pas mis à jour, effectuez l'opération et arrêtez votre serveur en deux temps sur l'interface.
- Lorsque j'agrandis le disque système, je n'ai pas de partition swap.
En effet nous avons préparé l'image Debian 6 pour fonctionner avec notre nouvelle infrastructure de stockage, et les disques sont maintenant “flat”, sans table de partition : votre disque est présenté au serveur virtuel comme xvda1.
L'avantage est que vous n'avez plus besoin d'editer la partition pour redimensionner le disque systeme (un resize2fs /dev/xvda1 fonctionne desormais “a chaud”).
Comme vous le remarquez, l'inconvénient pour l'instant est que le swap a disparu également, seul le nouveau système de stockage sachant le gérer en disque supplémentaire : vous pouvez creer un fichier swap si besoin en attendant d'être migré (dans l'année) sur ce nouveau système.
Je vous invite à lire l'explication technique ici
- Comment configurer gandi-config dans le package gandi-hosting-vm ?
Le package gandi-hosting-vm est installé sur toutes les images configurées par notre équipe technique. Il installe les fichiers directement dans les bons repertoires et vous disposez d'un fichier de configuration pour modifier son comportement au démarrage de la VM dans /etc/sysconfig/gandi. Plus d'information : http://lacuisinedegandi.net/post/2010/10/28/Modification-des-OS-standards-par-Gandi
- Les tentatives de détachement du disque se termine par une erreur.
Dans le cas d'un détachement de disque et en dehors d'un incident sur notre plate-forme d’hébergement, la cause principale est la présence en mémoire d'applications qui utiliseraient encore des fichiers sur le disque à détacher. Typiquement quand le noyau ne peut pas rendre le disque au sous-système Xen, il affichera un message d'erreur dans la sortie 'dmesg'.
En utilisant 'lsof' ou 'fuser' vous pourrez identifier quelle(s) application(s) utilisent encore la ressource.
- Comment connaître l'état de mon serveur ? Comment corriger mon serveur après un incident ?
Si le serveur virtuel ne démarre plus, détacher le disque principale pour le ré-attacher sur un autre serveur afin de vérifier le système de fichier par la commande fsck. Si le disque sur le deuxième serveur est sdf : fsck -nf /dev/sdf pour avoir une idée des erreurs puis fsck -f /dev/sdf. Pendant que le disque est encore attaché, regarder dans les fichiers de log dans /var/log (notamment kern.log, messages) pour avoir une idée du problème bloquant et de sa résolution.
En réattachant le disque sur le serveur initial et en passant une opération de démarrage, la situation devrait etre rétablie.
Les disques supplémentaires peuvent etre vérifié de la meme manière sur le serveur si il a démarré ou sur un deuxième serveur en détachant puis attachant le disque par la commande fsck. Vérifier que le disque est bien attaché au serveur mais pas monté. Si le disque est sdg, umount /dev/sdg démonte le disque et fsck -nf /dev/sdg permet d'avoir connaissance des problèmes puis fsck -f /dev/sdg permet de corriger le système de fichier en répondant au question.
- J'obtiens un message “expr: warning: unportable BRE” au redémarrage du service réseau ou à l'installation du package.
Comment le message l'indique cette information est un warning qui tient au fait que la version locale de la commande expr est un peu vieille par rapport à la gestion des expressions régulières. Ce warning peut etre ignoré.
- Sur CentOS, des erreurs iSCSI apparaissent dans les logs toutes les secondes.
CentOS installe par défaut iscsi et iscsid, que vous pouvez arreter et/ou désinstaller, nous les utilisons pour la partie backend mais pas sur les serveurs virtuels, cela n'impactera pas le fonctionnement du serveur et évitera de remplir les logs.
- Sur CentOS, Gsync m'envoie des erreurs, apparemment un manque de modules python : “ImportError: No module named ctypes”
Il est alors nécessaire de suivre la procédure suivante :
- installer et activer le repository EPEL - installer le package python-ctypes
Gsync fonctionne (Merci à Christophe Gimenez pour cette remontée).
- J'ai mis à jour mon noyau, le serveur plante, j'ai un disque de données en XFS
Les nouveaux noyaux ne supportent pas XFS, il faudra créer un disque qui sera au format Ext4 sur notre plateforme puis y transférer les données.
- J'ai le message d'erreur “Nom ou service inconnu” lorsque j'essaye de me connecter à mon serveur !
Vous n'avez pas indiqué la bonne adresse IP, ou le serveur n'existe pas sur cette IP. Vérifiez le status de votre serveur sur la page d'administration
- Pourquoi mon serveur n'a pas de graphe d'utilisation de la mémoire vive ?
Les ressources monitorées le sont par notre infrastructure Xen, la mémoire vive devra être vérifiée par un programme fonctionnant dans le serveur virtuel, plus de détails ici
- Puis-je utiliser mon propre noyau ?
Le noyau utilisé par un serveur virtuel au démarrage est fournis par l'infrastructure Xen. Les noyaux installés par les distributions ou par une compilation locale ne peuvent être utilisés. L'équipe de Gandi fournit une liste de version de noyau associable avec votre serveur. Voir la question suivante pour choisir la version du noyau.
- Comment mettre à jour le noyau de mon serveur ?
Le noyau utilisé pour démarrer un serveur virtuel est associé au disque 'principal'. Ce disque est indiqué comme 'Disque de boot' dans la page de détail du serveur virtuel dans le compte client rubrique hébergement. Dans la page détaillée de ce disque - accessible en cliquant sur le nom du disque - vous pouvez choisir la version du noyau associée. Après validation de l'opération il vous faudra stopper puis démarrer votre machine virtuelle.
- Gsync ne parvient pas à faire toutes les sauvegardes ?
Cela est dû au paramétrage du système de fichiers en ce qui concerne les options pour inotify, cela prévient le kernel d'un changement dans un dossier concernant Gsync, si ces options sont trop basses, Gsync ne fera pas la sauvegarde en entier. En Gandi AI, passez par le support pour que nous adaptions les valeurs, en mode expert, voici les directives à modifier dans le fichier /etc/sysctl.conf :
fs.inotify.max_user_instances = 128 fs.inotify.max_user_watches = 8192 fs.inotify.max_queued_events = 16384
- J'ai des erreur “end-request: I/O error, dev xvdx , sector xxxxxxx” sur chaque disque avec le kernel 2.6.36
Les “write barriers” font partie d'un mécanisme utilisé par les systèmes de fichiers journalisés pour garantir l'ordre d'arrivée de certaines requêtes vers le disque. L'implémentation actuelle est peu efficace et sur le point d'être améliorée. Leur impact sur les performances est fort pour de rares problèmes de corruption en cas de crash au mauvais moment. LVM (“device-mapper”) et notre configuration Xen actuelle ne supportent pas cette fonctionnalité.
Votre FS détecte la capacité du disque à gérer cette fonction au montage, en tentant de poser un “write barrier”. L'erreur (normale) retournée par le sous-système “disque” est enregistrée par le système de gestion des requêtes de manière “systématique” et provoque ce log ainsi qu'un message comme “JBD: barrier-based sync failed on XXX” qui peuvent être ignorés.
Si cette erreur apparaît en dehors de ce contexte (pendant le boot, a l'attachement de disque) ou accompagné d'un autre type de message, il faut bien sûr toujours s'inquiéter.
- impossible d'ouvrir /dev/xvda (comme indiqué dans la procédure de redimensionnement)
A partir d'avril 2011 Gandi a mis en place une nouvelle infrastructure de stockage en parallèle de l'ancienne basée sur LVM. Dans le nouveau modèle le disque principale de votre serveur ne contient plus de table de partition. Le système de fichier est directement dans le disque /dev/xvda1.
Si le fichier /proc/partitions ne contient plus xvda mais seulement xvda1 vous êtes dans ce cas. Il vous suffira de faire un resize2fs sur /dev/xvda1 pour redimensionner votre disque sans passer par l'étape de fdisk :
resize2fs /dev/xvda1
La commande peux retourner une erreur indiquant de vérifier le système de fichier.
- Je vois des processeurs dans /proc/cpuinfo, cela correspond-il à mes coeurs virtuels ?
Ce que vous voyez est en fait les processeurs de la machine physique, pour voir les processeurs virtuels, il est préférable d'utiliser la commande “top” puis d'appuyer sur la touche “1” pour voir les coeurs séparés.
- Puis-je disposer d'IP failover, si un serveur plante pour basculer sur un second ?
En utilisant l'API hosting Gandi (http://doc.rpc.gandi.net) et en une interface supplémentaire sur votre serveur avec le service en 'maitre'. Vous pouvez ainsi monitorer votre serveur/service et avec l'API détacher votre interface supplémentaire de votre serveur (vm.iface_detach) puis attacher cette interface sur le 2eme serveur chez Gandi avec le service en 'esclave' que vous aurez préparer (vm.iface_attach). Une fois l'interface migrer en moins de quelques minutes (si tout va bien), vous pourrez pinguer la gateway par défaut pour demander un clear ARP.
Si votre serveur secondaire est chez un autre fournisseur de 'cloud', la solution DNS avec un TTL très bas peux être une solution en gardant en tête que les caches DNS des fournisseurs d’accès modifie le TTL des zones pour configurer leur valeur de TTL bas (ex Free/Proxad).
Une autre solution est d'utiliser un redirecteur devant vos services qui dispatchera vos visiteurs entre vos 2 instances suivant la disponibilité (failover) ou même en balance de charge. Par exemple : si votre service est accesible en HTTP, un simple reverse proxy tel que Varnish ou un Nginx sur une machine en amont pourra faire l'affaire.
Evidemment mettre cette machine sans redondance ne fait que déplacer le SPOF (Single point of failure).
* J'ai quitté le mode Gandi AI et je n'arrive pas à donner des privilèges à des utilisateurs mysql même sous root *
Vous avez quitté le mode Gandi AI en activant les droits root sur votre serveur.
Seulement vous avez une erreur (errno 1044) lorsque vous tentez sous l'utilisateur 'root' de donner des privilèges à un utilisateur sur une base de données/table.
Cela vient du fait que l'utilisateur 'root' ainsi que ses droits ne figure pas dans la table 'db' qui se trouve dans la base 'mysql'. Vous pouvez le constater en faisant :
SELECT * FROM mysql.db;
Vous devrez donc faire l'ajout suivant :
INSERT INTO mysql.db (Host, User, Db, Select_priv, Insert_priv, Update_priv, Delete_priv, Create_priv, Drop_priv, Grant_priv, References_priv, Index_priv, Alter_priv, Create_tmp_table_priv, Lock_tables_priv, Create_view_priv, Show_view_priv, Create_routine_priv, Alter_routine_priv, Execute_priv, Event_priv, Trigger_priv) VALUES('localhost','root','%','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
Aussi n'oubliez pas de :
FLUSH PRIVILEGES;
L'utilisateur root que ce soit de puis phpmyadmin ou le client mysql, pourra attribuer des droits/privilèges à des utilisateurs sur des bases de données et/ou tables.