Tag: serveur dédié | Page 12

Transférer des fichiers d'un serveur à un autre avec rsync photo

Transférer des fichiers d’un serveur à un autre avec rsync sous Linux

7 April 202204 mai 2012 by Matt Biscay · Lecture: 3 minutes

Il arrive très souvent que l’on ait besoin de transférer des fichiers rapidement, d’un serveur à un autre par exemple.

Bien sûr, on peut utiliser le FTP mais il y a beaucoup plus rapide et efficace : je vous présente rsync.[no_toc]

Synchronisation distante

rsync (remote synchronization ou “synchronisation distante” en français) est un logiciel libre de synchronisation de fichiers (disponible sous toutes les plateformes).

La synchronisation est unidirectionnelle, c’est-à-dire qu’elle copie les fichiers de la source en direction de la destination.

rsync est donc utilisé pour réaliser des sauvegardes incrémentales ou pour diffuser le contenu d’un répertoire de référence.

Je vous donne ici les deux commandes que j’utilise quotidiennement lors de ma gestion des serveurs.

Copier tous les fichiers d’un répertoire du serveur A dans le répertoire équivalent du serveur B

Premièrement, connectez-vous via SSH à votre serveur A. Voici la commande :

/* Copie tous les fichiers de /home/website/ vers serveur B. */
rsync --ignore-existing --progress /home/movies/*.* matt@serveurB.net:/home/movies/Code language: PHP (php)

Explications:

--ignore-existing signifie que si le fichier existe déjà, on ne le remplace pas.
--progress montre la vitesse du transfert et les noms des fichiers transférés.
matt@serveurB.net est le nom du login SSH (matt) associé à l’adresse du serveur B (IP ou nom de domaine).
/home/website/ : répertoire vers lequel copier les fichiers.

En lançant cette commande, je récupère sur le serveur B tous les fichiers qui se trouvent dans le répertoire /home/movies/ du serveur A. Je ne remplace pas les fichiers existants : étant donné que je ne synchronise qu’avec rsync, ce serait inutile.

WordPress : retrouver le bouton “Publier”

6 October 201616 avril 2012 by Matt Biscay · Lecture: 2 minutes

Problème : plus de bouton “Publier” sous WordPress

wordpress_icon_blue Juste après la migration des bases MySQL, alors que je pensais que tout était bon, je vais sous WordPress pour raconter mes aventures et… plus de bouton “publier” mais un bouton “Soumettre à relecture” comme pour les guests ! Tout cela alors que je suis loggué comme admin, il y a un truc qui cloche.

Après avoir cherché un peu, il s’avère que j’ai copié directement les fichiers de bases de données mais que MySQL n’a pas les droits dessus. Du coup, toutes les tables sont en lecture seule, comme me l’a indiqué une petite requête simple :

Failed to save field : SQL alter table `wp_posts` modify `ID` bigint(20) unsigned not null default NULL auto_increment failed : Table 'wp_posts' is read only

Solution : attribuer les bases de données à mysql

Vous avez besoin de modifier les droits d’accès et d’écriture des fichiers de bases de données. Il faut soit se connecter à distance en SSH sur votre serveur ou en local sur votre machine et lancer la commande chown.

On se met donc dans le répertoire de travail de MySQL :

cd /var/lib/mysql/

et on attribue à l’utilisateur mysql les droits à nos bases de données :

chown -R mysql:mysql *

MySQL : résoudre l’erreur “Access denied for user debian-sys-maint@localhost”

1 April 202210 avril 2012 by Matt Biscay · Lecture: 1 minute

Problème : l’erreur “Access denied for user debian-sys-maint@localhost” au lancement de MySQL

Lors de la migration de mes bases de données d’un serveur à l’autre, j’ai aussi déplacé la base mysql qui contient tous les utilisateurs, droits… pour ne pas avoir à tout refaire.

Le problème, c’est que chaque installation de MySQL crée un utilisateur de maintenance – debian-sys-maint sur notre serveur Debian – avec un mot de passe unique.

Solution : penser à copier /etc/mysql/debian.cnf

En copiant les bases de données, il faut également penser à copier le fichier /etc/mysql/debian.cnf dans lequel se trouve, entre autres, le mot de passe SQL de l’utilisateur spécial maintenance de Debian.

DNS : résoudre l’erreur fatale “la liste des serveurs récupérée ne correspond pas à celle donnée”

8 April 202204 avril 2012 by Matt Biscay · Lecture: 2 minutes

Problème : ns.kimsufi.com ne semble pas être dans la liste des serveurs

Lors de l’appariement de votre nom de domaine au serveur et au cours d’un Zone-Check du domaine, vous pouvez tomber sur l’erreur suivante :

---- fatal ----
cohérence avec la liste des serveurs de noms donnée
f: La liste des serveurs récupérée ne correspond pas à celle donnée :

ns.kimsufi.com/2001:41D0:3:1C7::1

L’erreur étant fatale, il est nécessaire de la corriger pour que le nom de domaine pointe bien vers le bon serveur.

La solution : incrémenter le numéro de série du Start Of Authority (SOA)

La solution est très simple : il suffit d’incrémenter le numéro de série du Start Of Authority (SOA). A titre d’exemple :

; skyminds.net
$TTL    84600
@	IN	SOA	ksXXXXXX.kimsufi.com. root.skyminds.net. (
			2012040301   ; serial number : YYYYMMDDHH
			3600         ; refresh : 1h suffit
			1h           ; update retry
			4W           ; expiry
			84600        ; TTL )
Code language: PHP (php)

C’est la valeur 2012040301 (au format YYYYMMDDHH) qu’il suffit d’incrémenter. Ensuite, il ne vous reste plus qu’à relancer bind9 :

/etc/init.d/bind9 restart

Migration de serveur : bonjour Kimsufi 750G

4 May 202228 mars 2012 by Matt Biscay · Lecture: 2 minutes

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.

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

1 April 202206 février 2012 by Matt Biscay · Lecture: 3 minutes

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!Code language: JavaScript (javascript)

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 failedCode language: JavaScript (javascript)

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.

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 failedCode language: JavaScript (javascript)

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.MYICode language: JavaScript (javascript)

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: 3420Code language: JavaScript (javascript)

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

5 April 202217 décembre 2011 by Matt Biscay · Lecture: 2 minutes

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)Code language: JavaScript (javascript)

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 = 256MCode language: JavaScript (javascript)

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.

Linux : résoudre les erreurs communes de clé GPG dans APT

30 September 202116 novembre 2011 by Matt Biscay · Lecture: 3 minutes

De temps en temps, il arrive qu’en faisant un apt update, on obtienne quelques erreurs de clés GPG, soit parce qu’elles ont changé, soit parce qu’elle n’ont pas été ajoutées en même temps que les dépôts auxquels elles sont associées.

Voici une petite compilation des situations que j’ai connu jusqu’à présent.

La clé publique n’est pas disponible : NO_PUBKEY

Le message d’erreur habituel, dont voici un exemple :

W: GPG error: http://ppa.launchpad.net maverick Release: Les signatures suivantes n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKEY 632D16BB0C713DA6Code language: JavaScript (javascript)

Edit : voici une simple commande Shell qui permet de récupérer la clé et l’ajouter au trousseau directement, en une seule ligne de code:

sudo apt-get update 2>&1 | 
sed -ne 's?^.*NO_PUBKEY ??p' |
xargs -r -- sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keysCode language: JavaScript (javascript)

Si vous souhaitez faire cela manuellement, voici la méthode manuelle :

Ce qui est important ici, c’est le code de la clé : 632D16BB0C713DA6. Nous avons besoin des 8 derniers caractères de cette clé pour taper notre commande. Ces 8 caractères sont 0C713DA6 donc dans le terminal, on entre :

gpg --keyserver hkp://keyserver.ubuntu.com:11371 --recv-key 0C713DA6Code language: JavaScript (javascript)

puis:

gpg -a --export 0C713DA6 | sudo apt-key add -Code language: JavaScript (javascript)

On relance enfin la mise à jour :

apt-get updateCode language: JavaScript (javascript)

La clé ayant été ajoutée, le message d’erreur disparaît.

Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH

5 April 202228 octobre 2011 by Matt Biscay · Lecture: 6 minutes

Aujourd’hui, nous abordons la sauvegarde des fichiers essentiels du serveur.

Backup Manager permet d’effectuer des sauvegardes quotidiennes du système : il crée des archives dans plusieurs formats de compression (tar, gzip, bzip2, lzma, dar, zip) et peut les exporter vers un serveur FTP.

Dans notre cas, nous allons l’installer et le configurer pour envoyer tout ce qui est important sur notre serveur sur le serveur FTP externe de sauvegarde fourni gratuitement par OVH (100 Go).

Etape 1 : installation de Backup Manager

C’est classique :

apt-get install backup-managerCode language: JavaScript (javascript)

A la fin de l’installation, un assistant se lance et vous permet de configurer des options par défaut. Ou vous pouvez configurer à la main, comme indiqué dans l’étape suivante.

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

5 September 202111 août 2011 by Matt Biscay · Lecture: 2 minutes

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-64Code language: JavaScript (javascript)

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

5 April 202210 juillet 2011 by Matt Biscay · Lecture: 2 minutes

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!Code language: JavaScript (javascript)

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

Serveur dédié : analyse des performances du serveur

9 April 202230 juin 2011 by Matt Biscay · Lecture: 2 minutes

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 :

← Précédent Suivant →