J'ai planté le serveur... ou comment récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH photo

Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH

J’ai lamentablement fait planter le serveur en voulant mettre le kernel à jour…

Heureusement, il existe le mode rescue chez OVH qui permet d’installer un linux provisoire sur le serveur et d’initier une connexion SSH pour que l’on puisse réparer le système.

Si jamais cela vous arrive, voici la marche à suivre.

Passage en mode rescue depuis le manager OVH

lifesaver

1. Aller sur le manager OVH > Dedicated > Infrastructure > clic sur votre serveur > clic sur l’onglet Server Status.

Lire la suite

Serveur dédié : activer X11 forwarding pour SSH photo

Serveur dédié : activer X11 forwarding pour SSH

x11

Si jamais vous avez besoin que votre serveur dédié vous renvoie une image ou quoi que ce soit de graphique via SSH, vous aurez très certainement besoin d’avoir l’X11 Forwarding activé.

Il ne l’est pas par défaut donc si vous obtenez l’erreur suivante:

X11 forwarding request failed on channel 0 

alors il vous faut paramétrer l’option dans la configuration SSH du serveur.

Etape 1 : installer xauth

Sur le serveur et sur le client, xauth doit être installé. Il ne l’est pas sur notre serveur Debian, donc on l’installe :

apt-get install xauth

Etape 2 : vérifier que X11 forwarding est activé dans SSH

Sur le serveur, on édite la configuration du daemon SSH :

nano /etc/ssh/sshd_config

Et on vérifie qu’on a bien ForwardX11 est bien à yes :

AllowTcpForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
AddressFamily inet

et sur le client, on édite aussi la configuration SSH :

nano /etc/ssh/ssh_config

avec :

ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Lire la suite

Bash : réparer les tables MySQL en cas de crash photo

Bash : réparer les tables MySQL en cas de crash

Bash Il arrive que parfois une table SQL soit complètement plantée, ce qui peut bloquer l’accès à la base de données et donc l’accès au site.

Pour éviter cela, j’ai écrit un petit script bash qui me permet de stopper le serveur MySQL, procéder à la réparation de toutes les tables de toutes les bases de données puis relancer le serveur MySQL, Apache et Varnish.

#!/bin/sh
# MySQL Auto-Repair
# Written by Matt - skyminds.net

# stop the MySQL server
/etc/init.d/mysql stop

# check for errors
myisamchk /var/lib/mysql/*/*.MYI

# ask permission to repair
read -p "Repair tables ? (y/n)" -n 1 -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
	# repair everything
	myisamchk -r /var/lib/mysql/*/*.MYI

	# restart servers
	/etc/init.d/mysql restart
	/etc/init.d/apache2 restart
	/etc/init.d/varnish restart
else
	/etc/init.d/mysql restart
fi

C’est le genre de petit fichier bash à garder au frais sur le serveur, facile à lancer en SSH depuis n’importe quel terminal en cas de besoin.

Rsync: rapatrier les fichiers du serveur à la maison photo 1, ET, phone home

Rsync: rapatrier les fichiers du serveur à la maison

Je vous ai déjà parlé de rsync pour transférer des fichiers d’un serveur à un autre.

Supposons maintenant que vous vouliez récupérer les fichiers qui sont sur votre serveur chez vous, à la maison.

Cela ne prend que quelques minutes à mettre en place et cela sert très souvent.

Etape 1 : ouvrir le port 22 dans la box ou le routeur

Rendez-vous dans l’interface d’administration de votre box ou routeur :

  1. si ce n’est déjà fait, attribuez une IP fixe à votre PC en identifiant l’adresse MAC de sa carte réseau.
  2. ouvrez le port 22 (SSH) en TCP et redirigez-le vers l’adresse fixe de l’étape précédente.

Voilà, le port est ouvert et redirigé au niveau du routeur.

Etape 2 : ouvrir le port 22 dans le firewall de la machine

Je suis sous Linux (Debian, Ubuntu, Mint…), j’utilise donc iptables en root :

iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 22 -j ACCEPT

Le port 22 est maintenant ouvert aux connections entrantes et sortantes sur la machine.

Lire la suite

BIND9 : supprimer le message

BIND9 : résoudre l’erreur “ignoring out-of-zone data”

Bien configurer BIND9 pour que tout fonctionne correctement n’est pas vraiment intuitif et le parcours est semé d’embûches.

Sur mon ancien serveur OVH, j’ai connu l’erreur suivante pendant des mois :

/etc/bind/skyminds.net.hosts:15: ignoring out-of-zone data (ksXXXXXXX.kimsufi.com)

Alors bon, cela n’empêche pas du tout le serveur DNS de faire son travail mais c’est quand même un peu gênant de savoir que la configuration n’est pas optimale.

Voici comment y remédier.

Problème : BIND renvoie l’erreur “ignoring out-of-zone data”

Lors d’un checkconf BIND :

named-checkconf -z

Vous obtenez ceci :

/etc/bind/db.skyminds.net:15: ignoring out-of-zone data (ks3094174.kimsufi.com)
zone skyminds.net/IN: loaded serial 2011020911
zone localhost/IN: loaded serial 2
zone 127.in-addr.arpa/IN: loaded serial 1
zone 0.in-addr.arpa/IN: loaded serial 1
zone 255.in-addr.arpa/IN: loaded serial 1

Ce qui n’est pas vraiment optimal.

Lire la suite

Migration de serveur : bonjour Kimsufi 750G photo

Migration de serveur : bonjour Kimsufi 750G

J’ai peu posté ces derniers jours et ce pour plusieurs raisons. Premièrement, il fait beau. Donc j’en profite, surtout qu’il fait aussi chaud qu’en mai-juin. Et deuxièmement, je viens de migrer le site sur un serveur plus puissant.

Migration entre deux serveurs

Il y a une grosse différence entre monter un serveur de A à Z, comme j’avais fait précédemment, et migrer données et programmes d’un serveur A à un serveur B.

L’important pour moi était de réutiliser au maximum mes configurations donc j’ai repris mes tutos un à un, tout en copiant les fichiers que j’avais précédemment créés ou édités sur le nouveau serveur.

Résultats ?

Et bien cela fonctionne très bien ! J’ai connu quelques mésaventures mais j’ai pris plein de notes donc il y a là de la matière pour quelques futurs articles. En gros le site a été indisponible pendant 1h samedi mais je pense que cela ne s’est pas trop vu.

Au niveau technique, on peut apprendre pas mal d’informations sur le processeur du serveur en lançant la commande :

less /proc/cpuinfo

L’ancien serveur était un Intel(R) Celeron(R) CPU 220 @ 1.20GHz et 2 Go de RAM.
Le nouveau serveur est un Intel(R) Core(TM)2 Quad CPU Q8300 @ 2.50GHz et 4 Go de RAM.

Lire la suite

MySQL : résoudre l'erreur

MySQL : résoudre l’erreur “Table is marked as crashed and last (automatic?) repair failed”

Hier soir, gros bug sur le site : plus moyen d’accéder aux pages du site ou de sauvegarder un article. Je lance un top, le serveur n’a pas l’air d’être surchargé du tout. Je relance Apache, Varnish et MySQL et là…

Stopping MySQL database server: mysqld failed!
/etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! ... failed!

Ah cette erreur-là, je l’ai déjà eue ! Je fais un peu de ménage et je relance MySQL :

/etc/init.d/mysql restart 
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
ERROR 144 (HY000) at line 1: Table './skyminds/wp_posts' is marked as crashed and last (automatic?) repair failed

Et là, c’est le drame : le terminal est dans les choux comme attendant quelque chose et en lançant le site, il n’y a plus aucune information. Rien que le design, plus d’articles. Gloups.

mysql table crash

Je jette un coup d’oeil sur le serveur, j’ai mes sauvegardes des derniers jours mais pas de tout ce que j’ai écrit aujourd’hui. Je tente un REPAIR mais phpmyadmin refuse catégoriquement :

SQL show index from `wp_posts` failed : Table './skyminds/wp_posts' is marked as crashed and last (automatic?) repair failed

La solution : lancer myisamchk

La solution que j’ai utilisé consiste à lancer la commande myisamchk, qui est une commande de bas niveau qui va vérifier et réparer notre table.

On commence par arrêter le serveur MySQL :

/etc/init.d/mysql stop

et on lance myisamchk avec ces paramètres sur notre base de données qui se trouve sous /var/lib/mysql/:

myisamchk -r -v -f --sort_buffer_size=128M --key_buffer_size=128M /var/lib/mysql/skyminds/wp_posts.MYI

Voilà ce que cela retourne :

- recovering (with sort) MyISAM-table '/var/lib/mysql/skyminds/wp_posts.MYI'
Data records: 0
- Fixing index 1
  - Searching for keys, allocating buffer for 295411 keys
  - Dumping 3420 keys
- Fixing index 2
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 3
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 4
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 5
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 6
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 7
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 8
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 9
  - Searching for keys, allocating buffer for 3421 keys
  - Dumping 3420 keys
- Fixing index 10
  - Searching for keys, allocating buffer for 1177347 keys
  - Dumping 275199 keys
- Fixing index 11
  - Searching for keys, allocating buffer for 1177347 keys
  - Dumping 275199 keys
- Fixing index 12
  - Searching for keys, allocating buffer for 1177347 keys
  - Dumping 275199 keys
Data records: 3420

On relance MySQL :

/etc/init.d/mysql start

et cette fois, tout se passe bien :

Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..

Tout est revenu mais je me dis que je devrais peut-être passer à 2 sauvegardes par jour…

Serveur dédié : configurer la limite mémoire pour PHP et Suhosin photo

Serveur dédié : configurer la limite mémoire pour PHP et Suhosin

suhosin_logo

Aujourd’hui, je vous livre la solution à un problème auquel vous avez peut-être été confronté lors de la configuration de votre serveur dédié – il s’agit d’une erreur que l’on peut trouver dans les fichiers logs d’Apache :

Dec 12 16:19:26 mail suhosin[22860]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '82.83.84.85', file '/home/skyminds/public_html/wp-admin/admin.php', line 96)

Etape 1 : paramétrage de memory_limit dans php.ini

On édite notre fichier php.ini :

nano /etc/php5/apache2/php.ini

On recherche la variable memory_limit et on l’augmente à 256MB :

; Maximum amount of memory a script may consume (128MB)
; http://php.net/manual/en/ini.core.php#ini.memory-limit
memory_limit = 256M

Note : vérifiez que vous éditez bien le bon fichier php.ini ! Je me suis aperçu après quelques essais que celui qui correspondait à mon installation était en fait /etc/php5/apache2filter/php.ini.

Lancez un phpinfo();pour être sûr du fichier à éditer.

Lire la suite

Serveur dédié : mettre à jour le noyau Debian de la Kimsufi photo

Serveur dédié : mettre à jour le noyau Debian de la Kimsufi

linux kernel

Aujourd’hui, on met à jour le noyau linux de notre installation Debian sur notre Kimsufi.

Un noyau à jour, c’est toujours mieux pour bénéficier des derniers patchs/améliorations/correctifs de sécurité du noyau.

OVH compile ses propres noyaux, offrant différentes options. Nous choisirons le noyau avec GRS : grsecurity est un correctif de sécurité pour le noyau incluant PaX, un système de contrôle d’accès à base de rôles et différents moyen de renforcer la sécurité générale du noyau.

Téléchargement du dernier noyau linux chez OVH

Une fois loggés en SSH, on se place dans le répertoire /boot :

cd /boot

On regarde ensuite la liste des noyaux linux modifiés par OVH pour les Kimsufi : ftp://ftp.ovh.net/made-in-ovh/bzImage/.

On récupère 2 fichiers : le fichier bzImage et le fichier System.map associé. Pour mon serveur, je prends les versions -grs-ipv6-64 : certaines mesures de sécurité sont incluses dans le noyau made in OVH (-grs), avec support de l’ipv6 sur un système 64 bits.

Nous prenons donc la dernière version du noyau ici : ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/:

wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/System.map-4.1.7-xxxx-grs-ipv6-64
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/bzImage-4.1.7-xxxx-grs-ipv6-64
wget ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-experimental/config-4.1.7-xxxx-grs-ipv6-64

Lire la suite

MySQL : résoudre le message

Résoudre le non-redémarrage du serveur MySQL : le manque d’espace sur une partition disque

Il y a quelques temps, j’ai eu la surprise de constater que le site était down au niveau de la base de données, dont le service refusait catégoriquement de redémarrer. En regardant les logs du serveur, voici ce que j’ai découvert :

/etc/init.d/mysql: ERROR: The partition with /var/lib/mysql is too full! failed!

La partition sur laquelle se trouvent les bases de données SQL était pleine ! Effectivement, un petit

df -h

m’a appris que la partition /dev/sda1 était pleine à 100% :

Sys. de fich.         Tail.       Occ.       Disp.       %Occ.       Monté sur
/dev/sda1            9,7G       9,3G          0        100%         /
tmpfs                  984M         0        984M          0%        /lib/init/rw
udev                   10M        2,7M       7,4M         27%       /dev
tmpfs                 984M          0        984M           0%       /dev/shm
/dev/sda2            452G       648M      429G          1%       /home

Lire la suite

Serveur dédié : analyse des performances du serveur photo

Serveur dédié : analyse des performances du serveur

Cela fait quelques mois que le nouveau serveur est en place et il est temps de faire un petit bilan au niveau des performances.

Charge processeur

Tout d’abord, bien que le serveur soit équipé des mêmes caractéristiques techniques (même CPU, même quantité de RAM), il s’avère qu’il est beaucoup plus réactif que l’ancien.

Le processeur n’est plus surchargé en permanence et lorsque l’on lance un top, la charge du processeur est le plus souvent entre 0.05 et 0.20, ce qui est idéal.

A titre de comparaison, l’ancien serveur avait une charge souvent supérieure à 2.

Analyse du temps de chargement des pages via Google Webmaster Tools

Il y a quelques semaines, je me suis connecté sur Google Webmaster Tools et lorsque j’ai atteint le graphique du temps de chargement des pages du site, j’ai eu l’agréable surprise de découvrir ceci :

serveur dedie response time 2011

Lire la suite

Serveur dédié : installer la dernière version d’APC par SVN

Notre serveur ayant besoin de mettre les données en cache pour plus d’efficacité, il peut s’avérer intéressant de maintenir APC à jour via SVN, histoire d’être sous une version “bleeding-edge”.

Méthode automatique : installation d’APC via Dotdeb

Commencez par ajouter les dépôts Dotdeb à la configuration APT.

Ensuite, il suffit d’installer APC avec :

apt-get install php-apc

Configuration d’APC

J’ai un peu tweaké ma configuration d’APC par rapport au précédent article. Éditez apc.ini :

nano /etc/php/7.4/conf.d/apc.ini

et ajoutez-y :

extension=apc.so
apc.enabled=1
apc.shm_size=128M
apc.stat=0
apc.ttl=7200
apc.user_ttl=7200
apc.enable_cli=1
apc.max_file_size=10M
apc.rfc1867 = On

Et on relance Apache :

/etc/init.d/apache2 restart

Voilà, vous possédez la dernière version d’APC sur votre serveur. L’opération est à renouveler de temps à autre, histoire d’être toujours à jour.